Compiler-Warnung: ...ist möglicherweise nicht initialisiert

[Martin K]

Ich verstehe es nicht, es kommt zu folgender Warnmeldung:

Zitat:

[Warnung] Unit1.pas(39): Variable 'Obj' ist möglicherweise nicht initialisiert worden

Dieser Code (vereinfacht):

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var i: integer; Obj: TObject;
begin
  for i:=0 to Memo1.Lines.Count-1 do
  begin
    if Memo1.Lines[i]='Parent' then
      Obj:=Self       // hier initialisiert
    else
    if Memo1.Lines[i]<>'' then
      Obj:=FindComponent(Memo1.Lines[i]) // hier auch initialisiert
    else
      Continue;      // nicht initialisiert, aber Schleife wird ja auch fortgesetzt
    if IsPublishedProp(Obj,'Font') then // <--- hier Warnmeldung ---
      {...}
  end;
end;

Kann mir das einer erklären :?: :?: :?:

[fwsp]

es ist in ner if-anweisung und damit logischer weise eventuell nicht initialisiert, da die if ja nicht true sein muss
wenn du weißt das es true wird, kannst du es einfach ignorieren.

[Martin K]

Aber ich komme doch gar nicht in die IF-Anweisung, wenn Obj nicht initialisiert ist:

Delphi-Quellcode:

{..}
    else
      Continue;  // nicht initialisiert, aber ich komme dann auch nicht in die IF-Anweisung
    if IsPublishedProp(Obj,'Font') then
   {..}

Oder?

Zitat:

Zitat von fwsp

es ist in ner if-anweisung und damit logischer weise eventuell nicht initialisiert, da die if ja nicht true sein muss
wenn du weißt das es true wird, kannst du es einfach ignorieren.

Hä?
Verstehe ich nicht.
Was hat das denn damit zu tun, ob die IF-Anweisung true oder false ergibt?
Überprüfen tut er die doch immer...

..außer, bei Continue !?!?

[SirThornberry]

Continue ist halt so eine Ausnahme die vom Compiler nicht berücksichtigt wird (ist ja nur ein besseres goto)

[himitsu]

Delphi-Quellcode:

else 
      Continue;

... versuchst mal so ... es muß einfach nur sichergestellt werden, das obj vorher was zugewiesen wurde, dann mekert delphi nicht:

Delphi-Quellcode:

else 
begin
      Continue;
      obj := nil;
end;

[Martin K]

Okay, der Compiler berücksichtigt das Continue nicht.
Das war's.

Aber zu einem Fehler kann es beim Ausführen dieses Codes nicht kommen ?!?

@himitsu:

Du meinst wohl:

Delphi-Quellcode:

{...}
   Obj := nil;  // nicht self
{...}

[Hawkeye219]

Mich würde ein Continue, das von ausführbaren Anweisungen gefolgt wird, eher verwirren.
Eine Initialisierung vor der Schleife finde ich persönlich sauberer.

Gruß Hawkeye

[Martin K]

Ja, das denk ich auch.
Also so:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject); 
var i: integer; Obj: TObject; 
begin
  Obj := nil; //<-- hier hinzugefügt
  for i:=0 to Memo1.Lines.Count-1 do 
  begin 
    if Memo1.Lines[i]='Parent' then 
      Obj:=Self
    else 
    if Memo1.Lines[i]<>'' then 
      Obj:=FindComponent(Memo1.Lines[i])
    else 
      Continue;
    if IsPublishedProp(Obj,'Font') then
      {...} 
  end; 
end;

[Mackhack]

Zitat:

Zitat von Hawkeye219

Eine Initialisierung vor der Schleife finde ich persönlich sauberer.

Gruß Hawkeye

Da hab ich grad mal ne Frage an euch...:

Ist es sauberer, besser,... direkt am Anfang einer Function/Procedure Variablen zu initialisieren oder bevor sie wirklich zum Einsatz kommen?

Delphi-Quellcode:

Var
  I : Integer;
Begin
  I := 0;
  For I := 0 To...
  ...
End;

oder so?

Delphi-Quellcode:

Var
  ...
  ...
  ...
  I := 0;
  For I := 0 To...
  ...

[SirThornberry]

dein Beispiel ist etwas daneben. Denn vor einer "For-Schleife" ist es völlig überflüssig die Zählvariable zu initialisieren weil der Wert niemals verwendet wird (der Compiler wird dir auch eine Meldung ausgeben)

[Mackhack]

Ok,

hast recht aber meine Frage damit noch nicht beantwortet.

[mkinzler]

das ist eher eine Geschmacksfrage.

[Mackhack]

Ok,

da ich es immer am anfang gemacht habe so sind alle Initialisierungen zusammen und man braucht dann nachher nicht mehr daran zu denken im Code.

[Vjay]

Dagegen mache ich es meist direkt an der Stelle, an der ich sie verwende, denn so ist der Abschnitt "zusammenhängend" und man spart sich später Scrollarbeit bzw. erspart sich meiner Meinung nach Verständnisprobleme.

Zu dem Compilerwarnungen/Hinweisen: Es ist natürlich klar dass Delphi nicht das Verständnis eines menschlichen Gehirns an den Tag legen kann um den Code zu "verstehen". Es sind ja auch nur Hinweise und Warnungen um dich auf evtl. Fehler hinzuweisen, mehr nicht. Bei meinen Projekten werde ich regelrecht davon überschüttet und da ich keine Lust habe sämtliche angeblich zweifelhaften Blöcke mit Compiler-Tags zu umschliessen tendiere ich inzwischen leider dazu die Warnungen und Hinweise komplett zu ignorieren.

Ist quasi wie mit den Verkehrsschildern und Gesetzen in Deutschland ;)

[Luckie]

Zitat:

Zitat von Vjay

Bei meinen Projekten werde ich regelrecht davon überschüttet und da ich keine Lust habe sämtliche angeblich zweifelhaften Blöcke mit Compiler-Tags zu umschliessen tendiere ich inzwischen leider dazu die Warnungen und Hinweise komplett zu ignorieren.

Der Schuss kann aber auch mal kräftig nach hinten losgehen. ;)

[Vjay]

Joa, wie mit den Schildern und Gesetzen auch, naja dann zahlt man halt einmal, aber dafür hat man sich eine Menge Zeit erkauft und bisher ging die Rechnung auf.
Aber Recht hast du natürlich, vor dem Release gucke ich die Liste schon einmal durch ;)

[Luckie]

Ich habe hier auch eine Unit von einem Kollegen, da hagelt es auch nur so Warnungen und Hinweise, wenn ich ein Build machen. :?

[Martin K]

Wenn ich ein Projekt/Unit fertig stelle, achte ich halt immer darauf, dass keine Fehler-, Warn- oder Hinweismeldung kommt.
Wenn nicht, dann doktere ich halt so lange am Code rum, bis keine einzige Meldung mehr kommt:
Dann weiß ich gleich, an diesem Code ist alles in Ordnung! :angel2:

Eine einzige Warnmeldung hab ich allerdings in manchen Projekten drin, die ich auch nicht wegbekomme:

Delphi-Quellcode:

uses
  {...} FileCtrl;

Zitat:

[Warnung] Unit1.pas(7): Unit 'FileCtrl' ist plattformspezifisch

Aber was soll's, muss man halt mit leben...
:roll:

[Hawkeye219]

Hallo Martin,

versuche es einmal mit

Delphi-Quellcode:

{$WARN UNIT_PLATFORM OFF}

Gruß Hawkeye

[Luckie]

Diese Warnung kann man ignorieren, wenn man weiß, dass man das Projket nicht nach Kylix portieren wird. Man kann diese Warnungen übrigens auch ausschalten:

Delphi-Quellcode:

{$WARN SYMBOL_PLATFORM OFF}  // TrailingBackSlash

Ich schreibe dann im Kommentar immer noch dahinter, warum ich sie ausgeschaltet habe, damit andere wissen, dass ich es bewußt getan habe und auch wissen warum ich diese Meldungen deaktiviert habe.

[Martin K]

Wie ich Meldungen auf diese Art ausschalten kann, dass weiß ich schon.
Aber das ist ja eigentlich nicht die feine Art, da könnte ich ja gleich {$WARNINGS OFF} um meinen ganzen Code schreiben.
Das ist ja wie, wenn ich eine Prozedur mit Exit; abbreche oder mit Application.Terminate; beende.

Alles halt nicht die feine Art :wink:

[Luckie]

Nein, so hast du nur die für dich nicht interessanten Warningen deaktiviert.

Und was spricht gegen Exit? In meinem aktuellen Projekt benutze ich es sehr "intensiv", um aus Prozeduren rauszuspringen, wenn Bedingungen nicht erfüllt sind. Ist wesentlich übersicherlicher als fünfach verschachtelte if-Bedingungen und entspricht auch wesentlich genauer dem tatsächlichen Programmfluss.

[Martin K]

Zitat:

Zitat von Luckie

Und was spricht gegen Exit? In meinem aktuellen Projekt benutze ich es sehr "intensiv", um aus Prozeduren rauszuspringen, wenn Bedingungen nicht erfüllt sind. Ist wesentlich übersicherlicher als fünfach verschachtelte if-Bedingungen und entspricht auch wesentlich genauer dem tatsächlichen Programmfluss.

Na gut, überzeugt.

Trotzdem deaktiviere ich aus Prinzip keine Warnmeldungen:
Wenn sie da ist, dann ist sie nunmal da und hat auch irgendwo einen Sinn.