Clean Coding: Funktionen

Kapitel 3 – Funktionen

Funktionen sollten klein gehalten werden. Wenn es nach Robert C. Martin geht, sollten sie nicht mehr als 20 Zeilen haben. Dazu kommt, dass eine Zeile nicht mehr als 80 Zeichen beinhalten sollte. Nur so wird gewährleistet, dass die Funktion genau einen Zweck erfüllt (SRP – Single Responsibility Principle) und in kurzer Zeit gelesen und verstanden werden kann.

Über die Namensgebung von Funktionen bin ich bereits im vorherigen Teil kurz eingegangen: Verb + optimal ein Nomen. Ein Name darf ruhig auch etwas länger als 8 Buchstaben sein, wenn dadurch der Sinn dahinter klar hervorgeht.

Die Anzahl der Parameter sollte so klein wie möglich sein: im Optimalfall gar keiner, im schlimmsten Fall drei, jedoch nie mehr. Noch schlimmer sind „ref“ und „out“ Parameter, die dem Leser noch weit mehr Zeit zum Verstehen abverlangen. Oft macht es mehr Sinn eine eigene Klasse(n) zu erstellen, die als Parameter übergeben wird/werden, da dies die Lesbarkeit erheblich verbessert.

Kommen wir nochmal auf SRP von vorher zurück: eine Funktion sollte immer genau eine Aufgabe haben. Was unter allen Umständen vermieden werden muss, dass eine Funktion nebenbei noch irgendwelche nicht deklarierten Tätigkeiten macht. Würde die Funktion „getOrder“ einen Order erstellen, wenn dieser nicht existiert, dann wäre dies ein solcher Fall. Dies geht nicht aus dem Namen der Funktion hervor und wäre somit schlichtweg falsch.

Ferner sollte aus dem Namen der Funktion hervorgehen, ob sie einen Rückgabewert hat und was dieser ist. Allerdings gilt hier zusätzlich, dass eine Funktion entweder etwas macht oder etwas zurückgibt – nicht beides. Dies bedeutet, dass eine Methode „save“ keinen Rückgabewert hat, sondern im Falle, dass etwas nicht klappt, eine Exception wirft.

Eine Funktion sollte einem klaren Ablauf (Top-Down) folgen, sprich sie sollten von oben nach unten gelesen werden. Zu Beginn werden eventuelle Ausstiegsbedingungen geprüft, die Logik abgearbeitet und am Ende das Ergebnis retourniert.