Eure besten Quellcode Kommentare...

[Memnarch]

@Himitsu:
Pack mal inen Funktionsnamen nen LR-Overwrite Character rein. Das ist lustig . Dann kannst du die dinge Teils spiegelverkehrt schreiben, und IDE und Compiler schluckens

[himitsu]

Geil, Variable rückwärts schreiben und umgedreht anzeigen.
Selbst wenn jemand den Namen abschreibt und sich in deine Klasse häcken will, dann kompiliert nichts, weil er ja verkehrtrum schreibt.




Die extrem jugendgefährdeten Kommentare hab ich aber besser mal weggelassen.
Sorry, war etwas genervt.
TJSONObject.ParseJSONValue gibt einfach wortlos NIL zurück, und keine Ahnung warum, denn in der Datei ist jetzt ein valides JSON-Objekt drin.
Vorher JSONObject.ToString entdeckt, dass es totalen Schrott produziert, wie z.B. keine " und sonstige Steuer und Nicht-ASCII-Zeichen zu kodieren, aber vorallem \ und " unkodiert zu lassen ist der Megaburner und gehört eigentlich mit Steinigung bestraft.
Und JSONObject.Parse hört einfach mitten drin auf, wenn ihm was nicht gefällt und lässt dann netterweise defekte/unvollständige Subobjekte zurück.
Delphi DBXJSON.pas aus Delphi XE.

Delphi-Quellcode:

J := TJSONObject.Create;
try
  J.AddPair(...);
  J.AddPair(...);
  ...

  // der DRECK im ToString kodiert die Steuerzeichen nicht
  //TFile.WriteAllText(Datei, J.ToString, TEncoding.UTF8);
  B := TEncoding.UTF8.GetPreamble;
  i := Length(B);
  SetLength(B, i + J.EstimatedByteSize);
  J.ToBytes(B, i);
  while B[High(B)] = 0 do Delete(B, High(B), 1);  // Trim, denn EstimatedByteSize gibt etwa 4 Mal zuviele Bytes zurück
  TFile.WriteAllBytes(Datei, B);
finally
  J.Free;
end;

//J := TJSONObject.ParseJSONValue(TFile.ReadAllText(Datei)) as TJSONObject;
J := TJSONObject.Create;
try
  J.Parse(TFile.ReadAllBytes(Datei), Length(TEncoding.UTF8.GetPreamble));

  // Bei Ladefehler hat das letzte SubObjekt (Size-1) eventuell keinen Namen und es knallt dann bei der Namenssuche
  if not Assigned(J) then
    raise Exception.Create('Fehler beim Laden der Datei');
  if not ((J.Size > 0) and Assigned(J.Get(J.Size-1).JsonString) and Assigned(J.Get('last_sql_columnwidth'))) then
    raise Exception.CreateFmt('Fehler beim Laden der Datei (Item %d)', [J.Size]);

  S := J.Get(ValueName).JsonValue.Value;  // Dieses .Value ist natürlich leer, darum oben auch .JsonValue.Value
  ...
finally
  J.Free;
end;

Der Code, wie er schön aussähr, aber nicht funktioniert:

Delphi-Quellcode:

J := TJSONObject.Create;
try
  J.AddPair(...);
  ...
  TFile.WriteAllText(Datei, J.ToString, TEncoding.UTF8);
finally
  J.Free;
end;

J := TJSONObject.ParseJSONValue(TFile.ReadAllText(Datei)) as TJSONObject;
try
  S := J.Get(ValueName).Value;
  ...
finally
  J.Free;
end;

[Der schöne Günther]

Delphi-Quellcode:

try
  (Gedöns)
except
  // Gibt schlimmeres
end;

[MaBuSE]

Zitat von Der schöne Günther:

// Gibt schlimmeres

Ja, eine Abmahnung zum Beispiel !

Ich hatte mal ein mittelgroßes Projekt (ca. 200 Forms) übernommen, bei dem das grundsätzlich so gemacht wurde.
Die Anwender hatten sich daran gewöhnt nach einer durchgeführten Aktion noch mal zu prüfen ob es geklappt hatte.

Die Mitarbeiter in der Abteilung wunderten sich nur, warum immer wieder falsche, unvollständige oder defekte Datenbankeinträge da waren.
Da wurde jeden Tag auf der Datenbank "repariert".

Als ich das Projekt übernahm, habe ich alle except end; gesucht und entfernt.

Ergebnis:
Die Anwendung war unbenutzbar. Im Sekundentakt sind Fehlermeldungen aufgetreten.
Bei jedem Create eines Formulars ist eine GPF aufgetreten. (Fehler in der Basisklasse)
Viele Copy & Pase Fehler. (Ein Mal falsch gemacht und immer wieder kopiert.)

Durch einige einfache Suchen & Ersetzen Aktionen waren mehrere 100 Fehler weg.

Die Anwender mussten umlernen. Keine Fehlermeldung = hat geklappt.
Dafür gabs ab und zu Fehlermeldungen, die automatisch geloggt und abgearbeitet wurden.
Nach ein paar Monaten war es dann "fehlerfrei".

Und 2 Leute arbeitslos, da sie nicht mehr den ganzen Tag die Datenbank reparieren mussten

Ich hasse Programmierer die so was verwenden

Delphi-Quellcode:

try
  ...
except
end;

FixInsight mahnt das zum Glück an.

Ich empfehle immer nur den "erwarteten" Fehler zu prüfen. Es kann ja immer etwas unerwartetes passieren

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
  end;
end;

...

begin
  Beispiel('Zwei');
end;

In unterem Beispiel wird ein String einer Integer Eigenschaft eines Objekts zugewiesen.
Der Programmierer hat daran gedacht, dass auch ungültige Zahlen wie z.B. "zwei" übergeben werden können.
Aber er geht davon aus , das MeinObjekt immer existiert. Was wenn MeinObjekt = Nil ist?
Das Beispiel unten würde dann zumindest eine Exception (oder GPF) werfen.

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    on E: EConvertError do
    begin
      // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
    end;
  end;
end;

...

begin
  Beispiel('Zwei');
end;

[himitsu]

TryStrToInt

Nacholgendes ist Beides das Gleiche,
auch wenn es kein schöner Code ist, außer da kommt wirklich "ständig" irgendwelcher Schrott, der aber niemanden interessiert.

Delphi-Quellcode:

i := StrToIntDef(S, 0);

try
  i := StrToInt(S);
except
  i := 0;  // S ist kein Integer
end;

Aber beim Debuggen wirst du schnell den Schuldigen erwürgen wollen, welcher Letzeres genommen hat, voallem wenn diese Funktion im Minutentakt mit Nichtintegern ausgeführt wird.

[Sherlock]

Oh, nichts überbietet ein gepflegtes

Delphi-Quellcode:

begin
  try
.
.
.
    Application.Run;
  except
  end;

end.

in der dpr...



Sherlock

[freimatz]

Nach dem "-->"

Code:

procedure TIsoPositionCmdTest.Test_InitData_CharacteristicID();
begin
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<referenceSystemCaseET>('DetermineReferenceSystemCase',
    rsc11EC);
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<TOrientationSet>
    ('AvailableToleranceZoneOrientationKinds', []);
  m_ReferenceSystemInformationServiceMock.SetFunctionResult<TSourceElementsKindSet>
    ('AvailableToleranceZoneOrientationSources', []);

  { Puh: Mit dieser Zeile bringt man Wissen um die Implementiereung in den Test. Auch wenn von der Implementierung,
    von welcher hier die Rede ist, am Besten niemand etwas wüsste ;-).
    Der Test hier will eigentlich nur herausfinden, ob das richtige Element aus den beiden Elementfenstern für das
    zu tolerierende Element herangezogen wird. Diese Logik ist allerdings im InitData gut versteckt und eingebettet,
    so dass auch der Test dazu InitData aufrufen muss. 
--> InitData ist nun aber einer der schlimmsten Orte auf Erden. Das Ungemach, welches einem dort begegnen kann, 
    ist zu düster und umfangreich um es hier detailliert aufzuzeigen.
    InitData startet auch die Berechnung. Man versucht es zwar über ValidForCalculation zu verhindern, aber auch diese
    Methode ist unzureichend implementiert. Man geht dann aber wenigstens davon aus, dass dann das Merkmal in seinem
    Calculate schon jammert wenn was nicht passt. Würde es auch tun. Allerdings bedient sich das Positionsmerkmal dazu
    eines Services und der Success jenes Calculate ist im SetUpMocks mit true intialisiert. Darf halt nicht sein und
    deswegen hier das umstellen auf false.}
  m_ReferenceSystemGeneratorServiceMock.SetFunctionResult<IReferenceSystemCalculationResult>('Calculate',
    CreateReferenceSystemCalculationResult(false, identityMat4C, identityMat4C, '', sraUndefinedEC));

  Self.InitStatusDatabaseWithIdsAndDelegate('Kr1', 'Zyl1');
  CheckInitDataCharacteristicID();
end;

[Mavarik]

Zitat von MaBuSE:

Delphi-Quellcode:

try
  ...
except
end;

Ich empfehle immer nur den "erwarteten" Fehler zu prüfen. Es kann ja immer etwas unerwartetes passieren

Delphi-Quellcode:

// Zahl in Value in MeinObjekt.IntegerProperty ablegen
procedure Beispiel(const Value: string);
begin
  try
    MeinObjekt.IntegerProperty := StrToInt(Value);
  except
    // Fehlerbehandlung wegen 'Zwei ist kein gültiger Integerwert.'
  end;
end;

...

begin
  Beispiel('Zwei');
end;

Unter dem Strich hast Du natürlich zu 100% Recht. Also gibt es "eigentlich" nix was man hierzu erwidern kann, oder?

Die eigentlich Frage lautet : Was ist Dir wichtiger...?

Beispiel :

Gegeben sein eine Software die bei 5000 Kunden im Einsatz ist.
Gegeben sein eine Routine die bei diesen Kunden jeden Tag 100 Briefe ausdruckt...

Es gibt ein Softwareupdate das im Footer die Seitenanzahl ausgeben kann. In diese Routine hat sich ein Fehler eingeschlichen.

Dadurch wird die Seitenzahl nicht eingedruckt. Der try except end Abfänger verhindert eine Fehlermeldung...

Status : Alle Kunden sind glücklich - alle Briefe wurde gedruckt. Alle können "fehlerfrei" arbeiten!

Bei jedem Kunden 100x pro Tag ein Exception Fenster. Ist keine Option. Das würde nur die Hotline überlasten.
Von jeder Exception eine E-Mail (500.000 Stk.) ist auch keine Option.

Dann doch lieber einen Anruf von einem Kunden oder zwei (mehr merken es nicht, weil keiner die Neuerungsliste gelesen hat) der mitteilt, dass die Seitenzahl fehlt...

Also so pauschal kann man also doch nicht sagen ein "Try Except End" ist immer böse...

Gut, die Qualitätskontrolle hat versagt...

Aber wer hat schon für so etwas ein Test-Team oder einen Unittest - 30 Jahre alter Software?

Positiver Nebeneffekt - Die Kunden sagen: "Das ein oder andere Funktioniert noch nicht, aber dafür gibt es keine Exceptions in der Software..."

Mavarik

PS.: Oje... was werde ich dafür wieder an Kommentaren ernten..

[himitsu]

Es geht vorallem um die leeren Try-Except, also wo im Fehlerfall rein garnichts gemacht wird, bzw. wo der Fehler fahrlässig nicht/falsch behandelt wird.

Fehler abfangen und loggen ist auch eine Behandlung.



zu deinem Beispiel:
* fehlt nur die Seitenzahl, aber das dokument kommt raus, dann isses OK
* wird dennoch die "Zahl" geschrieben, aber mit einem falschen Wert, dann wird es schon problematischer
* wird garnichts mehr gedruckt, andere Teile fehlen im Ausdruck oder sind dadurch falsch, dann wäre es nicht nett, wenn der User die Fehlermeldung nicht bekommt

[JasonDX]

Ich würde zudem argumentieren dass die Qualitätsprüfung insb. dann fehlschlägt, wenn kein offensichtlicher Fehler auftritt. Wenn denen eine Exception um die Ohren fliegt, wird das Update nicht rausgehen. Weil aber Fehler geschluckt werden, sind Kleinigkeiten falsch die den Testern nicht auffallen, und der Kunde bekommt die Bananensoftware zum selbertesten.
Aber gut, jeder darf selbst die Qualität seiner Software bestimmen.


(was schreibst du dann eigentlich in deine Patch-/Update-Beschreibungen? "Druckt Seitenanzahl - vielleicht"?)