Einrückungsstil

[Rolf b]

Für den "Rotz" werde ich mich nicht entschuldigen, deine Ausdrucksweise gegenüber Gunnar war genau das.

Abgesehen davon hast Du natürlich nicht ganz unrecht, ob eine Funktion "zu lang" ist, wird nicht von ihrem Platzverbrauch auf dem Bildschirm bestimmt. "Passt nicht auf den Bildschirm" ist aber schon ein Smell, der einen nachdenken lassen sollte, ob man vielleicht zu viel an einer Stelle macht.

Deswegen habe ich ja auch Jos Funktion seziert - sie passt locker auf einen Bildschirm, ist aber trotzdem zu lang (=bündelt zu viele Funktionen) und kann mehrfach entkernt werden.

Andere Funktionen sind vielleicht 200 Zeilen lang, aber es ist sinnlos sie aufzuteilen, weil möglicherweise viele Datenfelder zu bewegen sind und eine Menge Zuweisungen durchgeführt werden müssen (wobei man dann natürlich gleich wieder schnuppern und sich fragen sollte, ob das verarbeitete Objekt gut designed ist).

Für den Programmierer ist es im worst case letztlich doppelt egal, ob er sich in einer Funktion verliert oder in einer Unzahl von Funktionen.

Nein, hier muss ich widersprechen. Es ist nicht egal. Einen algorithmisch komplizierten Trümmerhaufen von 200 Zeilen wirst Du im Normalfall nicht unittesten können. Er macht auch viel Mühe, ihn zu verstehen. Sowas schreit eher nach einer eigenen Klasse mit mehreren kleinen Methoden. DIESE kannst Du dann separat testen und kommst viel besser klar. Und wer die Hauptfunktion liest, die den Rest orchestriert, kann bei gut gewählten Namen der aufgerufenen Funktionen gleich sehen was sie tun und kann das Thema Top-Down aufnehmen.

"Form follows function", hast Du gesagt - aber was ist hier "function"? Es ist die korrekte Arbeitsweise des Programms, die Wartbarkeit, und die Testbarkeit. Die Form für gute Testbarkeit sind kleine, überschaubare Funktionen, die genau eine Sache tun.

Das einzige Gegenargument ist, dass gerade PHP viel Overhead für einen Funktionsaufruf hat. Das ist in PHP 7 schneller geworden, aber die Differenz zwischen inline code und einem Funktionsaufruf ist immer noch signifikant. Aber - wenn jemand Dinge baut, die performancekritisch sind, dann muss man fragen ob PHP die richtige Sprache für den Anwendungszweck ist (oder die ZEND Engine die geeignete Ausführungsumgebung). Wenn man eine sauber aufgeteilte Realisierung hat und dann durch Profiling feststellt, dass der Overhead für den Aufruf einer Funktion der Bottleneck ist, DANN kann man in NACHHINEIN eine Funktion inline verschieben. Sowas sollte man nicht vorher tun.

Rolf