...im Übrigen ist jahrelange Praxis weder eine notwendige noch eine hinreichende Bedingung für die Fähigkeit, guten Code zu produzieren).
Klar: Ich kauf mir Bücher darüber, wie man Autos repariert und -wupps- bin ich Mechaniker.
Und dann kauf ich mir noch Bücher, wie man guten Code produziert, zitiere daraus und -täterää- bin ich guter Programmierer. Selten so gelacht.
Zitat:
Auch break und continue sind gängige Prxis und trotzdem nichts anderes als bessere Gotos. Und sorry, wenn die Sprache einen mehr oder weniger zwingt sowas zu verwenden, dann ist eben die Sprache sch***e. Und trotzdem ist's ein Smell.
He he, "break" und "continue" werden von Clean-Code Verfechtern (praxisorientiert
) propagiert, alle Refactoring-Tools, die ich kenne, propagieren das. Aber trotzdem gibt es noch Leute, die es ablehnen. Na ja, kann natürlich Codeschmell sein. Für mich ist das: "Klare Sprache, um auszudrücken, was jetzt passieren soll".
Zitat:
Maps aka Dictionaries ersetzen gefühlte 90% aller case-Konstrukte in solchen Fällen mehr als gut und haben dabei sogar noch die passende Semantik.
Das ist korrekt, aber nicht notwendigerweise lesbarer.
Nur, weil man ohne 'case', 'break', 'continue', und (ja, einige fordern das sogar) 'for' auskommen kann, heißt das nicht, das diese Konstrukte überflüssig bzw. code smell sind. In der Folge wäre nur RISC wirklich 'Clean'.
Das Motto muss lauten: "So lesbar wie möglich mit so wenig Code wie nötig" und nicht "So wenig keywords wie nötig". Dann ist das guter Code.
Ein Case-Konstrukt aus 1000 Fällen ist per se Blödsinn, aber 3-4 Fallunterscheidungen sind allemal übersichtlicher als irgendwelche Maps oder Dictionaries, die an ganz anderer Stelle befüllt werden:
Delphi-Quellcode:
Case WerteBereich(Messwert) of
ZuKlein :
GibFehlermeldungAus('Der Wert ist zu klein');
GeradeRichtig :
VerarbeiteDen(MessWert);
ZuGross :
GibFehlermeldungAus('Der Wert ist zu groß');
end;
erfordert keine Zeile Kommentar, wohingegen
WerteBereichAuswertungsDictionary[WerteBereich(Messwert)]();
kurz und knapp ist, aber nicht gerade lesbarer. Als Programmierer muss ich nachdenken, was der Code macht. Und blättern muss ich auch, um herauszubekommen, was unter welchen Umständen ausgeführt werden soll. Mist, schon wieder 10 Sekunden unnütz nachgedacht, nur weil der Programmierer zu faul ist, sich klar und verständlich auszudrücken.
Abschließend noch eins:
Denk mal darüber nach, wie viel einfacher und klarer Programme wären, wenn man keine Dogmen aufstellt ("break, continue, case sind böse"), sondern auf einer Ebene darüber (inklusive über den Tellerrand blicken und so) über den perfekten Code siniert: Erst dann kommt man weiter.