AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

[CleanCode] Beispielklasse TDataLocation

Ein Thema von neo4a · begonnen am 18. Feb 2012 · letzter Beitrag vom 20. Feb 2012
Antwort Antwort
Seite 3 von 4     123 4   
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#21

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 16:02
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.
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.017 Beiträge
 
Delphi 12 Athens
 
#22

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 16:11
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#23

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 16:15
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.
Andreas
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#24

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 16:18
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?
Andreas
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
10.934 Beiträge
 
Delphi 12 Athens
 
#25

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 16:27
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
neo4a

Registriert seit: 22. Jan 2007
Ort: Ingolstadt
362 Beiträge
 
Delphi XE2 Architect
 
#26

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 16:32
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.
Andreas
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#27

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 17:14
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 = 'testthen 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.)

Geändert von Furtbichler (18. Feb 2012 um 17:22 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.017 Beiträge
 
Delphi 12 Athens
 
#28

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 20:51
Das "Codeoptimierungen" bezog sich nicht grundsätzlich auf die Performance.

Selbst das einfache if Assigned(V) and V.Xyz then gilt doch auch schon als Sowas.

PS: Von der Funktion her ist hier natürlich Delphi-Referenz durchsuchenStrToIntDef die direkte Übersetzung.
IsANumber und TryStrToInt, zusammen mit einem IF, wäre mehr die umständlichere logische Übersetzung.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#29

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 18. Feb 2012, 21:05
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.
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.007 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#30

AW: [CleanCode] Beispielklasse TDataLocation

  Alt 20. Feb 2012, 13:32
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!
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (20. Feb 2012 um 13:36 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:15 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz