Als Einleitung: Jeder programmiert so, wie er will und so, wie seine Teamkollegen es zulassen (so er denn welche hat).
...erzeugt wieder zusätzlichen Code..
In 99.9% aller Fälle ist Performance kein Thema, denn es kommt in erster Linie auf das Verfahren an. Die restlichen 0.1%, also die performancekritischen Programmteile, werden entweder mit 'inline' refaktorisiert oder aber explizit komplex aber dafür notwendigerweise performant implementiert und entsprechend kommentiert.
Das Ausbleiben von Refaktorisierung sollte jedoch immer die Ausnahme sein, nie die Regel.
Zitat:
...aber ständig zwischen verschiedenen Stellen im Code hin- und herspringen zu müssen...
Gerade das musst Du eben nicht machen, denn wenn dort z.B. steht:
If CountryIsInEuroZone(myCountry) then
ist es für das Verständnis des eigentlichen Codes irrelevant, wie die Funktion umgesetzt ist. Und wer denn die Implementierung sehen will, für den bieten moderne
IDE im Übrigen über Tastaturkürzel diese Möglichkeit (Delphi scheint irgendwie nicht dazu zu gehören).
Zitat:
...ich persönlich habe lieber möglichst den gesamten Code der Abfrage gleichzeitig im Blick. Ich habe auch kein Problem damit, eine mehrzeilige if-Abfrage geistig zu parsen.
Ich unterstelle Dir mal, das Du weder professionell, noch produktiv oder im Team programmierst. Denn dein Kollege würde dich für deine Ignoranz hassen. Desweiteren bezweifle ich, das Du nach 6 Monaten noch weisst, was mit dem mehrzeiligen Ausdruck gemeint ist. Mir ist die Zeit im Übrigen zu schade, um das 'im geiste zu parsen'.
Auch wenn das folgende Argument an die 100 Mio nicht irrenden Fliegen erinnert: Überlege mal, weshalb Refaktorisierungstools so beliebt sind.
Zitat:
Und Kommentare gibt es ja zum Glück auch noch.
Die weitaus meisten Kommentare sind böse, lügen, werden nicht gepflegt oder gar nicht erst angelegt. Du bist ja ein Beispiel dafür, da Du keinen Kommentar für solchen Code benötigst (Du schaffst es ja, ihn geistig zu parsen. Ich übrigens auch, habe aber keine Lust darauf).
Zitat:
Als Faustregel kann man sagen, dass ich Code nur dann in eine Funktion auslagere, wenn sie an anderen Stellen auch noch mal gebraucht wird.
Yo, DRY eben. Mach das mal präventiv: "Ich schreib ne allgemeingültige Funktion dafür. Wer weiss, vielleicht kann ich sie mal gebrauchen" und schon bist Du deinem Ziel, guten Code zu schreiben, ein Stück näher.
Ich stelle immer wieder fest, das gute Programmierer durch die selben Phasen der Codeformatierung und Implementierung gehen:
-Erste Gehversuche und verzweifelte Suche nach Syntaxfehlern.
-Sichere Beherschung der Syntax, Selbstüberschätzung weil Programme auch mal funktionieren.
-Entdecken des DRY-Prinzips und Verfechter des All-In-One-Codes.
-Erste größere nachhaltige Projekte und Verzweiflung beim Pflegen des Codes.
-Kommentierung von Code, damit man ihn nach einem Jahr noch versteht.
-Verringerung der Codekomplexität, weil die Einsicht entsteht, das Einfachheit (kurze Methoden), Lesbarkeit, Wartbarkeit und Robustheit untrennbar miteinander verbunden sind.
-Weitere Vereinfachung des Codes.
-Noch mehr Vereinfachungen.
...
Die Frage ist doch: Wo stehst Du und wo willst Du hin?
um dagegenzuhalten, genialer Code kann so formatiert werden dass er komplett unleserlich wird.
Ich glaube, genialer Code ist immer lesbar. Weil er einfach ist. Wäre er kompliziert, wäre er nicht genial, sondern würde höchstens das Problem lösen.
Zitat:
Hast Recht. Aber wieso nicht?
[Edit] Ich habe gerade ein nettes Zitat gefunden:
Zitat von
Nick Hodges:
Remember, the future maintainer is the person you should be writing code for, not the compiler.