[CleanCode] Beispielklasse TDataLocation

[neo4a]

Zitat:

Zitat von himitsu (Beitrag 1151714)

Und ich bin mir fast sicher, daß selbst CleanCode was dagegen hätte.

So, wie Du das hier formulierst, müsste es eine Frau sein ;) (CC = Coco Chanel)

Aber im Ernst: Genauso wie bei der Code-Formatierung sollte auch der Programmfluß keine "Mätzchen" machen. D.h., nur weil etwas funktioniert/kompiliert, muss man es noch lange nicht machen.

Ich hatte bislang Exceptions auch eher als Ausnahmen eingesetzt und im finally/except-Block nie funktionalen Code hinterlegt. Also war meine erste Reaktion bei Furtbichlers Code: Und wo wird nun eigentlich der out-Parameter belegt?

Andererseits wird in anderen Sprachen sehr offensiv mit Exceptions gearbeitet und das nicht nur in Ausnahmefällen. Vielleicht Zeit für mich, auch hier etwas umzudenken.

[himitsu]

Größtes Gegenargument gegen Exceptions zur regulären Programmsteuerung.

Delphi-Quellcode:

try
  X := StrToInt(S);
except
  X := 0;
end;

Und jetzt debugge mal ein Programm, wo Sowas oder Ähnliches in jeder zweiten Codezeile vorkommt.
Das macht absolut keinen Spaß mehr, wenn der Debugger ständig anhält.

Die Exceptions zu ignorieren ist auch keine Lösung, denn dann werden vom Debugger auch Exceptions ignoriert, welche man gerne erfahren würde.

[neo4a]

Zitat:

Zitat von Furtbichler (Beitrag 1151712)

Deine Lösung beschreibt den Vorgang direkt ('Wenn noch nicht erfolgreich, versuche die nächste Möglichkeit').

Ich habe aber mit einer Häufung von "if not ..."- Anweisungen gearbeitet. Empfohlen wird dagegen, immer auf positive Erfüllung hin zu prüfen, weil es sich wohl "natürlicher" und einfacher erfassen lässt.

[neo4a]

Zitat:

Zitat von himitsu (Beitrag 1151729)

Größtes Gegenargument gegen Exceptions zur regulären Programmsteuerung.
...
Das macht absolut keinen Spaß mehr, wenn der Debugger ständig anhält.

Die Exceptions zu ignorieren ist auch keine Lösung, denn dann werden vom Debugger auch Exceptions ignoriert, welche man gerne erfahren würde.

Was spricht gegen spezielle Exception-Klassen?

[Uwe Raabe]

Zitat:

Zitat von neo4a (Beitrag 1151731)

Zitat:

Zitat von himitsu (Beitrag 1151729)

Größtes Gegenargument gegen Exceptions zur regulären Programmsteuerung.
...
Das macht absolut keinen Spaß mehr, wenn der Debugger ständig anhält.

Die Exceptions zu ignorieren ist auch keine Lösung, denn dann werden vom Debugger auch Exceptions ignoriert, welche man gerne erfahren würde.

Was spricht gegen spezielle Exception-Klassen?

In diesem Fall wäre das wohl EConvertError und den schaltet man besser nicht generell ab.

[neo4a]

Zitat:

Zitat von Uwe Raabe (Beitrag 1151732)

Zitat:

Zitat von neo4a (Beitrag 1151731)

Zitat:

Zitat von himitsu (Beitrag 1151729)

Größtes Gegenargument gegen Exceptions zur regulären Programmsteuerung.
...
Das macht absolut keinen Spaß mehr, wenn der Debugger ständig anhält.

Die Exceptions zu ignorieren ist auch keine Lösung, denn dann werden vom Debugger auch Exceptions ignoriert, welche man gerne erfahren würde.

Was spricht gegen spezielle Exception-Klassen?

In diesem Fall wäre das wohl EConvertError und den schaltet man besser nicht generell ab.

Schon klar. Aber ich hatte mich nicht so sehr auf das nicht gequotete Beispiel bezogen als vielmehr auf eine Möglichkeit, Exceptions zur Programmsteuerung zu nutzen ohne sich ständigen Debugger-Halts auszusetzen.

[Furtbichler]

Zitat:

Zitat von himitsu (Beitrag 1151722)

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

Delphi-Quellcode:

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.

Zitat:

Zitat von himitsu (Beitrag 1151729)

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:

Delphi-Quellcode:

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

[himitsu]

Das "Codeoptimierungen" bezog sich nicht grundsätzlich auf die Performance.

Selbst das einfache

Delphi-Quellcode:

if Assigned(V) and V.Xyz then

gilt doch auch schon als Sowas.

PS: Von der Funktion her ist hier natürlich StrToIntDef die direkte Übersetzung.
IsANumber und TryStrToInt, zusammen mit einem IF, wäre mehr die umständlichere logische Übersetzung.

[Furtbichler]

himitsu, wir reden nicht von Code, den man in der Praxis verwenden würde, sondern von Code, der dem 'Clean-Code' Prinzip entspricht. Und das verteufelt nun mal Funktionen wie 'StrToIntDef' oder 'TryStrToInt', alleine schon wegen dem Namen, aber vor allen Dingen der oben bereits ausführlich aufgeführten Gründen wegen.

Dir liegt Clean-Code nicht, das heißt doch aber nicht, das Du dann keinen guten Code zu Papier bringen kannst.

Lies mal das Buch, ich vermute nämlich, das Du es nicht kennst. Es ist sehr empfehlenswert.

In die gleiche Kerbe schlägt übrigens Quasar.

[Stevie]

Ich bin der Meinung, dass solche TryWasAuchImmer(out Wert) und WasAuchImmerDef(DefaultWert) Routinen ihre Daseinsberechtigung haben und keineswegs im Widerspruch zu Clean Code stehen.
Was wäre die Alternative? Am Beispiel TryStrToInt verdeutlicht müsste man entweder testen, ob der gegebene Stringwert in einen Integer gecastet werden kann oder die Exception abhandeln - überall, wo man einen String in einen Integer umwandeln muss - bisschen DRY verletzt oder?

Anderes Einsatzgebiet der Try... Methoden ist bei mir immer, wenn es sein kann, dass ich ein Objekt zurückbekomme, oder auch nicht (z.b. bei der Reflection ein TryGetProperty(PropertyName)). Somit fehlt ein zusätzliches Überprüfen auf Assigned.

Aber auch hierzu gibt es unterschiedliche Meinungen.

Zum Thema Exceptions - zu deutsch Ausnahmen - sie heißen nicht aus Zufall so. Sie sind nicht dazu da, den flow control des Programms zu steuern!