Meldung: Var nicht initzialisiert obwohl wert zugewiesen?!

[jottkaerr]

Hallo,

Zitat von f4k3:

Nr. 1 - [Pascal Warnung] Unit1.pas(90): W1036 Variable 'res' ist möglicherweise nicht initialisiert worden

Delphi-Quellcode:

  ...;

  case op of
    '+':  res := op1 + op2;
    '-':  res := op1 - op2;
    '*':  res := op1 * op2;
    '/':  res := op1 / op2;
  end;

wenn op keinen dieser vier möglichen Operatoren enthält, kann Deine Prozedur nicht vernünftig weiterarbeiten. Einen sinnvollen Default für den Operator gibt es m.E. nicht. Ich würde daher das Werfen einer Exception bevorzugen:

Delphi-Quellcode:

  ...;

  case op of
    '+':  res := op1 + op2;
    '-':  res := op1 - op2;
    '*':  res := op1 * op2;
    '/':  res := op1 / op2;
    else raise Eception.CreateFmt('Ungültiger Operator ''%s''!', [op]);
  end;

Das verhindert auch die Compiler-Warnung.

Zitat von f4k3:

Nr. 2 - [Pascal Warnung] Unit1.pas(143): W1036 Variable 'zei' ist möglicherweise nicht initialisiert worden

Delphi-Quellcode:

  ...;

  if Sender = Button10  then zei := '0';
  if Sender = Button1   then zei := '1';
  if Sender = Button2   then zei := '2';
  if Sender = Button3   then zei := '3';
  if Sender = Button4   then zei := '4';
  if Sender = Button5   then zei := '5';
  if Sender = Button6   then zei := '6';
  if Sender = Button7   then zei := '7';
  if Sender = Button8   then zei := '8';
  if Sender = Button9   then zei := '9';
  if Sender = Button11  then zei := '.';

Hier solltest Du mit "else if" arbeiten und ein

Delphi-Quellcode:

  else
    raise Exception.Create('Unbekannter Button');

anhängen. Diese Variante verhindert ebenfalls eine Compiler-Warnung.

jkr

[Sharky]

Zitat von jottkaerr:

....Hier solltest Du mit "else if" arbeiten und ein. ...

Ein unbekannter Button sollte das ja eigentlich nie sein. Und anstelle von IF und Co würde ich einfach bei jedem der Buttons die Tag Eigenschaft setzen (Button1.Tag = 1; Button2.Tag = 2 usw). Und dann einfach:

Delphi-Quellcode:

procedure TDemo_Form.ZeiButtonClick(Sender: TObject);
const
  CharArray: array[1..11] of Char = ('1', '2', '3', '4', '5', '6', '7', '8', '9', '0', ',');
var
  zei: Char;
begin
  .
  .
  zei := CharArray[(Sender as TButton).tag];
  .
  .
end;

[jottkaerr]

Hallo,

wenn der gezeigte Code Teil eines Taschenrechners sein soll, dann sind doch die Buttons wahrscheinlich mit den Ziffern und dem Komma bzw. Punkt beschriftet. Wieso nimmst Du dann nicht einfach

Delphi-Quellcode:

if (Sender as TButton).Caption = '' then
  raise Exception.Create('Unbeschrifteter Button');

zei := (Sender as TButton).Caption[1]

jkr

[Muetze1]

Man sollte seinen Programmablauf nicht von Inhalten auf der Oberfläche abhängig machen sondern immer von den extra gehaltenen Daten, aus denen die Oberfläche befüllt wird. Die Trennung Oberfläche und Daten ist wichtig und es ist ein Graus, wenn jemand anfängt so etwas zu programmieren. Schon alleine die Codeänderungen, wenn er anstatt dem "-" ein "Minus" reinschreibt und bei "*" ein "Multiplizieren". Schon fängt man an und ändert Code, der schon mal komplett fertig war. Oberflächen immer aus dem Spiel lassen. Anderes gutes Beispiel ist immernoch: funktioniert das Programm noch, wenn es übersetzt wurde? Wenn man so programmiert nicht.

Der gezeigte und genutzte Weg über den Instanzenvergleich ist schon ein gut gehbarer. Der Weg über den Tag ist auch ein Weg, der mir persönlich aber nicht so gefällt, weil man sich damit selbst die Möglichkeiten verbaut. Was ist, wenn es eine ähnliche Funktionalität mit einer andere Gruppe Elemente auf der Oberfläche benötigt wird? Keine eindeutigen Tags und wenn dann noch die Anwendung random features erzeugt, dann landet das falsche Elemente mit dem falschen Tag in der falschen Behandlungsroutine und die löst anhand des Tags was falsches aus. Anderes Gegenargument für Tags: Es ist schwer nachvollziehbar. Es ist für jeden anderen Kollegen, der an den Code ran muss ein riesiger Aufwand über den OI die Tag Verteilung zu ermitteln und auch den entsprechenden Ablauf. Den Code anzuschauen bringt rein gar nichts sondern man muss erst alles im Detail untersuchen. Dies erhöht die Wartbarkeit und die Lesbarkeit in's negativ unermeßliche.

Daher: bester Ansatz immernoch der Instanzenvergleich. Man sieht welche Funktion bei welchen Element ausgelöst wird, der Code "dokumentiert" sich durch den benannten (!) Elementenamen fast komplett selbst und es kann ohne Probleme übersetzt werden, etc.

[RavenIV]

[offtopic]
Ich bin auch ein Verfechter davon, GUI und Daten und Code zu trennen.
Manche Leute haben aber einen totalen anderen Standpunkt.

z.B. mein Vorgänger.
Er hat alles was geht im OI eingetragen.
Zudem hat er viel Programmlogik in die Datenbank ausgegliedert.
Dadurch wurde der Code natürlich erheblich kürzer, aber sehr viel schlechter überschaubar und schlechter lesbar.
Alleine, bis ich durchgestiegen bin, wie welche Query mit welcher Query verknüpft ist (MasterSource, KeySource, usw.) hat es lange gedauert und ich hab bis heute noch nicht alles rausgefunden.
Weiterhin bezieht er sich im Code oft auf die Captio irgendwelcher Komponenten. Erschwerend kommt hinzu, dass ein Button mit Beschriftung "Hinzufügen" als Namen "addbtn" oder "Button1" hat. Somit kann man erst mal keine Verbindung vom Text "Hinzufügen" zu "addbtn" finden.

Was ich aber gelernt habe:
Lass die Leute so arbeiten, wie sie es haben wollen. Nicht jeder möchte seinen Code recyclen oder in einigen Monaten überhaupt noch verstehen.
Solange die Typen nicht in meiner Abteilung arbeiten, kann es mir wurscht sein, was sie mit ihrem Code anstellen.
Wenn von denen einer zu uns in die Firma kommen würde, würde er erst nochmal zur Welt kommen. Wenn man im Team arbeiten muss, geht so was eben nicht.

So, wieder genug aufgeregt.
[/offtopic]

[mkinzler]

[OT]
Dann stell dir vor du würdest in eine Firma kommen und er wäre dein Vorgänger
[/OT]

[RavenIV]

Zitat von mkinzler:

[OT]
Dann stell dir vor du würdest in eine Firma kommen und er wäre dein Vorgänger
[/OT]

Mein Vorgänger war er ja schon.

Viel schlimmer wäre es, wenn er mein Vorgesetzter wäre.
Ich glaube, ich würde sofort wieder kündigen.