Grob übersetzt würde CleanCode dann aber bedeuten auf nahezu alle Codeoptimierungen zu verzichten.
Ja. Zunächst schon. Heutzutage sind die Rechner schnell genug, und mal ehrlich: An wie vielen Stellen in einer komplexen Applikation kommt es auf Performance an? Wo es sinnvoll und nötig ist, wirft man das
CC-Konzept natürlich vereinzelt über Bord. Aber mit Ansage, d.h. Kommentar.
Wichtig bei Performance ist eh das Verfahren und nicht die Codetricks.
Zitat:
Denn mit voller booleanischen Auswertung kann der Code nur in if Assinged(DS) then if DS.Active then if Assinged(DS.FindField('x')) then if not DS.FieldByName('x').IsNull then if DS.FieldByName('x').AsString = 'test' then
enden.
Selbst mit Zeilenumbrüchen und Einrückung wird es nicht lesbarer.
Wie wäre es mit einer ordentlichen Exceptionbehandlung? Ein integraler Bestandteil von
CC.
Größtes Gegenargument gegen Exceptions zur regulären Programmsteuerung.
Delphi-Quellcode:
try
X := StrToInt(S);
except
X := 0;
end;
Ein ungücklich gewähltes Gegenbeispiel, das zudem keines ist.
Was bedeutet '
Exception'? Und wieso passt das nicht zur 'regulären' Programmsteuerung? Genau, weil es Ausnahmen sind. Wenn Du in der Regel in deinem Code davon ausgehen musst, das 'S' auch keine Zahl beinhalten kann, dann solltest Du das auch so ausdrücken:
Delphi-Quellcode:
If IsANumber(S) Then
x:=StrToInt(S);
Oder eben, nicht ganz
CC, aber dafür praktischer:
if tryStrToInt(S,X) then
.
Noch etwas zu Exceptions: Ich würde sie nicht im Sinne von globalen 'Goto' verwenden. Dafür können Sie nämlich verwendet werden (und eigentlich sind sie das auch). Eine gute
Exception-Verwaltung versteckt die konkreten Probleme einer Implementierung (z.B.
TCP-Timeout,
DB-Probleme etc.) und verarbeitet sie. Falls die
Exception dazu führt, den Programmfluss abbrechen zu müssen (Datenübertragung bei
TCP-Timeout ist irgendwie unnütz), wird die
Exception 'abstrahiert' nach oben gereicht. Der aufrufenden Schicht ist es egal, warum die Übertragung nicht funktioniert hat (Details stehen im Log), nur DAS sie nicht funktioniert hat, ist entscheidend. Übrigens kann eine Datenübertragung auch per RS-232, Profibus o.ä. ablaufen. Insofern ist es problematisch, den technischen Grund (oder: die ursprüngliche
Exception) weiterzureichen: Bei einer nachträglichen Erweiterung ist nicht gesichert, das der Code noch funktioniert, denn es könnte sein, das nur spezielle Exceptions abgefangen werden (ETCPTimeoutException z.B.)