Antwort an „Der Martin“ verfassen

Hallo Rolf,

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

... gegen die ich auch nichts einzuwenden habe. Nur ist sie nicht in jedem Fall sinnvoll.

Eine "große" Funktion, die viele Dinge nacheinander tut, schreit nach Zerschlagung in kleinere Teile, die separat getestet werden können.

Eine große Funktion, die viele Dinge nacheinander tut, entsteht normalerweise Schritt für Schritt. Testen, ggf. nachbessern, nächsten Schritt hinzufügen, wieder testen.

Ich hab schon Funktionen von Kollegen gesehen, die 2000 Zeilen lang waren.

Ich auch.

Nachdem ich die Brechstange angesetzt hatte, wurden eine Menge kleinerer Funktionen draus, und eine Hauptfunktion, die alles gesteuert hat (das war ihre "eine Sache").

Wenn man die Teilschritte für sich sinnvoll kapseln kann, ist das auch gut. Das kann man aber nicht immer. Die Fensterprozeduren in einer Windows-Anwendung sind in der Regel lange switch-Anweisungen, die anhand der Message-ID entscheiden, was gerade zu tun ist. Das können schon mal mehrere Dutzend verschiedene Messages sein, die bearbeitet werden müssen. Da ist es vorteilhaft und üblich, alles zusammenzuhalten, was zu einem Fenster gehört. Die einzelnen case-Zweige sind dann in der Regel kurze Blöcke mit wenigen Zeilen, manchmal nur einem Funktionsaufruf.

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.

Gleichen oder fast gleichen Code identifizieren und als separate Funktion auslagern ist gut.

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.

Ja. "Lange" Funktionen finde ich bei rein linearem Programmablauf dennoch übersichtlicher.

Kannst du dich an Apache 2.0 erinnern? Da gab es in der Standardinstallation eine Konfigurationsdatei httpd.conf. Ab 2.2 oder 2.4 wurde die dann in viele Fragmente heruntergebrochen, die includiert wurden. Ich fand das katastrophal unübersichtlich.

Live long and pros healthy,
 Martin

--
Fische, die bellen, beißen nicht.
freiwillig, öffentlich sichtbar
freiwillig, öffentlich sichtbar
freiwillig, öffentlich sichtbar

Ihre Identität in einem Cookie zu speichern erlaubt es Ihnen, Ihre Beiträge zu editieren. Außerdem müssen Sie dann bei neuen Beiträgen nicht mehr die Felder Name, E-Mail und Homepage ausfüllen.

abbrechen