Eure besten Quellcode Kommentare...

[Robert Marquardt]

Das IOCCC-Programm das wie Line Garbage aussieht ist schon viele Jahre alt. Da ist dieser Node doch ein eher schwaechlicher Versuch.

[himitsu]

Delphi-Quellcode:

type ☻ = Integer;

function ｡◕‿◕｡(☺: Integer): ☻;
begin
  Result := not ☺;
end;

Delphi-Quellcode:

var ☺, ☻: Integer;

☺ := 123;
☻ := ｡◕‿◕｡(☺);

Ist zwar kein Kommentar, aber diesen Code muß man doch auch nicht kommentieren, denn da erkennt man sofort was abgeht.

Und ja, der Code ist richtig, kompiliert und läuft sogar.
Quelle: http://www.delphipraxis.net/191928-k...ehlerhaft.html

[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.

[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..