Blocks zur Quelltext-Strukturierung

[Alexander (HH)]

Moin Moin!

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

* Tippaufwand! ;-)
* Optisch sehr ähnlich zu einer normalen Methodendeklaration oder auch zu einem Stückchen JSON.
* 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.

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

Und ja, die Diskussionen, wie groß eine Bildschirmseite ist, ist wesentlich älter als mein Diplom.

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

Das kann ich heute auch nur jedem raten. Nicht als einbetonierte Regel, die zu solchem Code führt:

  
function Spaghetti_Part1(...)  
{  
  // 20 Zeilen Code  
  return Spaghetti_Part2(...)  
}  
  
function Spaghetti_Part2(...)  
{  
  // 20 Zeilen Code  
  return Spaghetti_Part3(...)  
}  
  
function Spaghetti_Part3(...)  
{  
  // 20 Zeilen Code  
  return Spaghetti_Part4(...)  
}  
  
function Spaghetti_Part4(...)  
{  
  // 20 Zeilen Code  
  return Spaghetti_Part5(...)  
}  
  
// usw. bis  
  
function Spaghetti_Part997(...)  
{  
  // 10 Zeilen Code  
  return 42;  
}  

Sondern als Richtschnur. Regeln kann man brechen. Man muß nur wissen, wann man sich an die Regeln hält (so oft wie möglich), und wann man sie ignoriert (selten, wenn nötig).

Eine andere Daumenregel: Eine Funktion oder Methode sollte immer nur einen einzigen logischen Schritt erledigen. Die "innersten" Funktionen bestehen dann teilweise nur aus zwei oder drei Zeilen Code, die nächste Schicht darüber ruft im wesentlichen die innerste Schicht auf, die Schicht darüber die Funktionen aus der Schicht darunter, und so weiter, bis zum Hauptprogramm.

Winzige Funktionen, bei denen für den Aufruf mehr Assembler-Code generiert wird als letztendlich im Funktionskörper steht, darf der geneigte Coder als inline deklarieren, wobei moderne Compiler das mit geeigneten Optimierungsflags auch schon automatisch können.

Alexander