array[1..10] auf Wert prüfen?

[Delphi.Narium]

Wenn mir der Compiler sagt, dass eine Variabel, ein Rückgabewert ... eventuell nicht initialisiert sein könnte, dass irgendwas undefiniert sein könnte ..., dann wird das behoben.

Ohne Wenn und Aber.

Zitat:

Zitat von Sherlock

Ein Entwickler, der einen Fall ignoriert, dessen Auftreten explizit erwähnt wird, sollte den Beruf wechseln.

Dem ist nichts hinzuzufügen.

Und wenn ein (semiprofessioneller) Hoppyprogrammierer ein Problem mit seinem Quelltext hat und hat nicht alle diese Warnungen (durch entsprechende Anpassung seines Quelltextes) behoben, sollte nicht wegen undefinierter Zustände, Zugriffverletzungen ... in irgendeinem Forum nachfragen, wo denn die Fehlerursache liegen könnte.

[hoika]

Hallo,
also ich habe Warnungen drin und das Programm stürzt nicht ab.

Also ist doch alles gut?

PS:

Zitat:

Habe schon unzählbare Warnungen dieser Art korrigiert und jedes einzelne Mal hatte der Compiler Recht und die Variable WAR nicht initialisiert.

Ich habe hier eine Warnung, da vertut sich der Compiler definitiv.
Ich kann das aber hier leider nicht posten.
Das ist aber die absolute Ausnahme.

[freimatz]

Zitat:

Zitat von hoika (Beitrag 1410739)

Also ist doch alles gut?

Nein. (Und nein, kein :wink:)

Und obwohl mir das Clean-Code-Pprinzip DRY sehr wichtig ist:

Zitat:

Zitat von Delphi.Narium (Beitrag 1410729)

Wenn mir der Compiler sagt, dass eine Variabel, ein Rückgabewert ... eventuell nicht initialisiert sein könnte, dass irgendwas undefiniert sein könnte ..., dann wird das behoben.

Ohne Wenn und Aber.

Zitat:

Zitat von Sherlock

Ein Entwickler, der einen Fall ignoriert, dessen Auftreten explizit erwähnt wird, sollte den Beruf wechseln.

Dem ist nichts hinzuzufügen.

Und wenn ein (semiprofessioneller) Hoppyprogrammierer ein Problem mit seinem Quelltext hat und hat nicht alle diese Warnungen (durch entsprechende Anpassung seines Quelltextes) behoben, sollte nicht wegen undefinierter Zustände, Zugriffverletzungen ... in irgendeinem Forum nachfragen, wo denn die Fehlerursache liegen könnte.

Ja, es gibt Fälle wo der Compiler nicht wissen kann, dass die variable initialisert ist. Das beduet aber dann nur, dass der Code nicht sauber ist. Im Notfall initialisiert man halt einmal zuviel.
Denn: jede Warnung die man ignorieren kann führt dazu, dass man eher eine Warnung übersieht, die wichtig ist. :!::!::!:

[Neutral General]

Zitat:

Zitat von hoika (Beitrag 1410739)

Hallo,
also ich habe Warnungen drin und das Programm stürzt nicht ab.

Also ist doch alles gut?

Du hast/hattest Glück.
Je nachdem was du machst oder falls du vllt den Code veränderst und sich dadurch zur Laufzeit der Inhalt des Stacks leicht verändert, dann hast du ggf. den Salat.
Deswegen gibt es keinen Grund solche Warnungen nicht ernst zu nehmen und die 10 Sekunden aufzubringen das Problem zu beheben.

Zitat:

Zitat von hoika (Beitrag 1410739)

Ich habe hier eine Warnung, da vertut sich der Compiler definitiv.
Ich kann das aber hier leider nicht posten.
Das ist aber die absolute Ausnahme.

Poste doch ein analoges Beispiel.
Bin mir fast sicher, dass der Compiler Recht hat :duck:

[himitsu]

Ich hatte gestern bei uns eine Funktion gefunden, da stand ganz am Ende etwas wie das

Delphi-Quellcode:

if xxx > 0 then
  zzz.FieldByName('fff').AsInsteger := xxx;

Früher war mal oben dem xxx was zugewiesen, aber das wurde gelöscht.

Dieses lokale xxx ist nicht initialisiert und kann potentiell jeden beliebigen Wert enthalten.
Zufällig war es zum glück lange Zeit 0 und es passierte nichts.

Tja, aber nun knallt es immernoch nicht, selbst wenn es plötzlich nicht mehr 0 ist ... im DataSet wird da "nur" das Feld mit "irgendeinem" beliebigen Wert überschieben. :stupid:

[freimatz]

So aus dem Gedächtis war das so etwas in der Art:

Delphi-Quellcode:

var bla: Integer;  f:Boolean;
begin
  f := TrittDerFallXEin;
  if f then begin
     i := HoleDenIWert();
  end;
  MacheWasAnders();
  if f then begin
     MachWas(i);
  end;
end;

Aber wie gesagt:

Zitat:

Zitat von freimatz (Beitrag 1410741)

Ja, es gibt Fälle wo der Compiler nicht wissen kann, dass die variable initialisert ist. Das beduet aber dann nur, dass der Code nicht sauber ist. Im Notfall initialisiert man halt einmal zuviel.
Denn: jede Warnung die man ignorieren kann führt dazu, dass man eher eine Warnung übersieht, die wichtig ist. :!::!::!:

[himitsu]

OK, hier stimmt es zufällig, aber irdenwann könnte mal wer auf die Idee kommen und eine der IF-Bedingungen ändern.

Und was spricht nun dagegen sich die 2 Sekunden zu nehmen und ein

Delphi-Quellcode:

else i := 0;

oder gantz oben einfach ein

Delphi-Quellcode:

i := 0

einzufügen?

[Rollo62]

Die zwei Sekunden gehen wohl fürs Posten in DP drauf :stupid:

WARNINGS: IMMER wie ERROR behandeln
HINTS : IMMER wie ERROR behandeln

Ein Release sollte man immer mit 0 Hints, Warnings, Errors kompilieren können.
So wird das bei mir gnerell als Vorgabe definiert.

Wenn ich Warnings/Hints akzeptiere, dann gibt es dazu immer eine spezielle "Ausnahmegenehigung".

Rollo

[himitsu]

Zitat:

Zitat von Rollo62 (Beitrag 1410747)

Wenn ich Warnings/Hints akzeptiere, dann gibt es dazu immer eine spezielle "Ausnahmegenehigung".

Wobei man diese Hints/Warnings "nur" an der entsprechenden Stelle dann auch deaktivieren kann.

[DeddyH]

Diese ganzen Kylix-Altlasten "Unit Dingenskirchen ist plattformspezifisch" schalte ich auch immer aus, ansonsten wird jeder Warnung und jedem Hinweis nachgegangen und die Ursache abgestellt.

[hoika]

Hallo,
so aus dem Stegreif

Delphi-Quellcode:

function GibMirEinenString(const AFlag: Integer): String;
begin
  Result:= '';  // ja, die Zeile ist wirklich drin 

  case AFlag of
    1: Result:= '1';
    2: Result:= '2';
  else
  begin
    if AFlag>100 then
    begin
      Result:= 'zu gross';
    end
    else
    begin
      Result:= '>2';  // hier kam die Compilerwarnung
    end;
  end;
end;

Die Methode hatte >500 Zeilen ...

[Neutral General]

Dabei kommt keine Warnung, das muss anders ausgesehen haben. (Habs extra getestet)

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1410752)

Diese ganzen Kylix-Altlasten "Unit Dingenskirchen ist plattformspezifisch" schalte ich auch immer aus, ansonsten wird jeder Warnung und jedem Hinweis nachgegangen und die Ursache abgestellt.

und die C++-Warnungen vonwegen Create ohne Parameter, überladene Property usw. was der CppBuilder nicht kann.

[DeddyH]

Das geht ja über die Projektoptionen ohne Compilerschalter.

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1410756)

Das geht ja über die Projektoptionen ohne Compilerschalter.

Global nur für sowas wie den C++-Schrott,

aber das Andere immer nur lokal, um die entsprechende Stelle.

[p80286]

@Hoika
Was ist mit Werten <1 ?

Gruß
K-H

[himitsu]

Zitat:

Zitat von Neutral General (Beitrag 1410754)

Dabei kommt keine Warnung, das muss anders ausgesehen haben. (Habs extra getestet)

Es fehlt ein END, das vom CASE, wenn ich das letzte END der Funktion zuschreibe.

Und ich würde wenigstens eine Meldung beim ersten

Delphi-Quellcode:

Result := ''

erwartet. (wurde zugewiesen aber nicht verwendet)


Ansonsten ist hier der String (gemanagte Typ) ein Problem, der per se immer initialisiert ist, entgegen einem Integer-Result.
Nur ist der eben extern initialisiert und das kann probleme geben, wenn der String wiederverwendet oder in einer Schleife genutzt wird.

[Dennis07]

Ich weiß, ist jetzt schon etwas älter dieses Thema, und ich habe mir gerade noch mal (durch Zufall) die offizielle Dokumentation der Wahrnung durchgelesen. Und diese besagt:

Zitat:

Sie können sich nur auf den letzten Wert eines for-Schleifenzählers verlassen, wenn die Schleife mit einer goto- oder exit-Anweisung verlassen wird.

Und genau das passierte in meinem Code:

Zitat:

Zitat von Dennis07 (Beitrag 1410459)

Delphi-Quellcode:

function AssertArray(AArray: TArray<Boolean>): Boolean;
begin
  for Result in AArray do
  begin
    if not Result then
    begin
      Exit;
    end;
  end;
end;

Ist also wirklich nichts dran auszusetzen. Das nur noch als kleiner Abschluss.