Hallo Martin,
Daher halte ich dem "und-Dogma" zum Ausgleich eine andere Faustregel entgegen: Nicht zerreißen, was eigentlich zusammengehört.
"Eine Funktion sollte eine Sache tun" ist eine durchaus gängige Lehre. Und es ist wichtig, denn andernfalls wird das mit den Unit Tests eine schwierige bis unmögliche Sache.
Eine "große" Funktion, die viele Dinge nacheinander tut, schreit nach Zerschlagung in kleinere Teile, die separat getestet werden können. Und wenn diese Teile zusammengehören, dann schreit das auch nach einer Ausgliederung in eine Worker-Klasse. Die wird bei Bedarf erzeugt, bekommt ggf. Objekte für Logging, DB-Zugriff und ähnliches injiziert, und kann dann schön autark vor sich hin wurschteln. Und man kann schön autark Unittests dafür schreiben.
Ich hab schon Funktionen von Kollegen gesehen, die 2000 Zeilen lang waren. Nachdem ich die Brechstange angesetzt hatte, wurden eine Menge kleinerer Funktionen draus, und eine Hauptfunktion, die alles gesteuert hat (das war ihre "eine Sache"). Nach etwas mehr Codeinspektion fand ich dann auch, dass diese kleineren Funktionen sich teilweise so sehr ähnelten, dass man sie gemeinsam implementieren konnte und nur passend zu parametrieren brauchte. Nachher waren es 500 Zeilen. Durch gutes Benennen der Teilfunktionen wusste man auch, was die einzelnen Codeteile taten und konnte sich top-down in den Code einlesen.
Pflichtlektüre ist hier Clean Code von Robert C. Martin. Problem ist nur, dass es scheinbar out of print ist und nur schlechte Nachdrucke erhältlich sind; bei Amazon beschweren sich etliche Käufer bitterlich über schlechten Kontrast und riesige weiße Ränder.
Rolf
sumpsi - posui - obstruxi