Blocks zur Quelltext-Strukturierung

[Alexander (HH)]

Moin Moin!

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

Das wird aber oft deckungsgleich, spätestens, wenn man den Code im Laufe der Jahre immer wieder anfassen muß, weil sich die Anforderungen ändern.

Glaub mir, ich wühle seit drei Jahren in teilweise über 30 Jahre altem MUMPS-Code, der von Amateuren zusammengefrickelt wurde. Ich kann Dir aus dem Code für wirklich jede schlechte Idee, auf die man beim Coden kommen kann, mindestens drei Beispiele zeigen. Auch für falsch aufgeteilte Funktionen, zu lange oder zu kurze Funktionen. Von Copy&Paste und Ignorieren der System-Doku will ich gar nicht anfangen.

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.

Nö, gute Programmierer schrieben den Code so, dass der für einen anderen Programmierer, der die Syntax der jeweiligen Sprache kennt, ohne weiteres lesbar und verständlich ist. Unverständliche Konstrukte werden mit Kommentaren versehen, die das Konstrukt erklären. Insbesondere, wenn man fiese Tricks für irgendwelche Optimierungen nutzt.

Um Mini-Optimierungen (Loop unrolling, Inlining und ähnliches) kümmert sich der Compiler. Die großen Optimierungen, angefangen bei Hints für den Compiler über Auswahl von Algorithmen und Datenstrukturen, sind immer noch Job des Programmierers.

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.

Natürlich sind LoC ein schlechtes Maß. Aber LoC ist besser als gar nichts. Und die (Daumen-)Regel "max. 20 LoC pro Funktion" verhindert einigermaßen, dass Leute alles in eine Funktion stopfen. Manchmal braucht eine Funktion 30 LoC, dann ignoriert man die Regel eben. Aber 100 oder 200 LoC sollten wenigstens eine Alarmlampe aufleuchten lassen. Sicherlich gibt es auch Fälle, wo 200 LoC in einer Funktion sinnvoll sind, aber die sind eher selten.

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

Der "logische Schritt" ergibt sich aber von selbst, wenn man das große Problem Stufe für Stufe in kleinere Schritte unterteilt. Dabei fallen Klassen- und Methodennamen fast von selbst an. Natürlich hält kein Plan der Wirklichkeit stand, aber mit etwas Übung muß man während der Programmierung am Plan nicht mehr viel ändern.

Alexander