Blocks zur Quelltext-Strukturierung

[1UnitedPower]

Meine Herren,

erstmal Danke für die ausführliche Antwort!

Gibt es irgendwelche Gründe die dagegensprechen Blöcke zur Quelltext-Strukturierung einzusetzen?

* Tippaufwand! ;-)

Ich bin nicht tippfaul und du offenbar auch nicht ;)

* Optisch sehr ähnlich zu einer normalen Methodendeklaration oder auch zu einem Stückchen JSON.

Das ist in der Tat bedenklich.

* Wenn Du den Code einer Funktion / Methode mit solchen Krücken struktuieren mußt, ist sie zu lang und sollte in kleinere Funktionen / Methoden zerlegt werden. Spätestens die Vergabe von Namen zeigt, dass Du eigentlich kleinere, eigenständige Funktionen / Methoden haben willst.

Meh, Funktionen sind doch vor allem dann sinnvoll, wenn man dadurch Wiederverwendbarkeit erzielen kann, nicht wenn ich irgendwas benennen kann.

Ob Du die Pseudo-Strukturen mit sinnlosen Labels und anonymen Blöcken baust oder stumpf mit Kommentarzeilen voll Line Noise, macht keinen Unterschied. Letztere schmeißt schon der Precompiler bzw. Parser raus, erstere macht so ziemlich jeder Optimizer im Compiler platt.

Mir geht es in erster Linie auch nicht um Performanz, davon bin ich lange Weg. Jeder kann für einen Computer programmieren, gute Programmierer programmieren für Programmierer.

Und beides ist IMHO falsch:

Ich habe im Studium noch gelernt, dass eine Funktion nicht länger als eine Bildschirmseite sein soll, wobei Bildschirm ein VT420 im VT100-Modus meint, also 25 Zeilen à 80 Zeichen, minus zwei oder drei Zeilen, die Editor und Terminal selbst brauchen.

Naja, die Bildschirme sind ja ein Zeuge dafür aus welcher Zeit diese "Best Practices" stammen. Ich sehe in solchen Aussagen keinen akademischen wert. Codezeilen halte ich sogar für ein ausgesprochen schlechtes Qualitätsmerkmal für Quelltexte. Usability und Reusability sind die beiden Faktoren, die ich für relevant bei der Qualitätsanalyse halte. Ein großes Thema dabei ist die richtige Stufe der Abstraktion ausfindig zu machen und eben nicht immer alles bis auf die kleinste Funktion runterzubrechen. Das mag dann zu einer Komponente mit unglaublicher Reusability führen, die Usability läuft aber von unten gegen 0.

Einige Hardcore-Profs waren der Meinung, dass ein Kommentar mit Dokumentationscharacter (POD für die alten Hasen, Javadoc für die Frischlinge) Bestandteil dieser 25 Zeilen ist. Die Daumenregel für Dokumentation besagt, dass die mindestens etwa doppelt so lang wie der Code ist, bleiben also etwa 14 Zeilen Doku und 7 bis 8 Zeilen Code pro Funktion. (Relaxtere Profs haben ein Doku-Code-Verhältnis von etwa 1:1 akzeptiert, sehr relaxte Lab-Ings haben auch mal Funktionen erlaubt, die die 80x25 Zeichen maximal ausgereizt haben.)

Wie gesagt mit dem Gedanken, Codezeilen oder Zeichen als Qualitätsmerkmal heranzuziehen kann ich nichts anfangen. Mal ein Beispiel: Wenn ich JSDoc-Syntax verwende, um spzeifizierende Kommentare zu machen, sind die 14 Zeilen Doku schnell erschöpft, Kommentare zu Implementations-Details sind da noch garnicht drin.

Eine andere Daumenregel: Eine Funktion oder Methode sollte immer nur einen einzigen logischen Schritt erledigen.

Das passt mir schon eher in den Kram. Wobei "ein logischer Schritt" ein dehnbarer Begriff ist ;)