Themen

Länge: So kurz wie möglich

Fokus: Immer nur eine Aufgabe

Parameter: Je weniger, desto besser

Modularität: Don't Repeat Yourself

Glossar

PDF

Kapitel bei Springer

https://link.springer.com/chapter/10.1007/978-3-662-71607-6_14

• Funktionen sollten so kurz wie möglich sein.
  Übersichtlichkeit erleichtert intellektuelle Beherrschbarkeit.
• Funktionen sollten genau eine Sache tun, die aber richtig.
  Unix-Prinzip: „Do one thing, and do it well.“
• In einer Funktion sollte nur eine Abstraktionsebene vorherrschen.
  Das fördert die Übersichtlichkeit und Verständlichkeit.
• Je weniger Parameter eine Funktion hat, desto besser.
  Mehr als drei Parameter sollten nie auftreten.
• Doppelungen im Code sollten grundsätzlich vermieden werden:
  „Don't Repeat Yourself“ (DRY).

Die Komplexität eines nützlichen Programms übersteigt die menschliche Auffassungsgabe bei Weitem. Alle Konzepte der Softwareentwicklung zielen deshalb auf die intellektuelle Beherrschbarkeit der Programmierung ab. Funktionen (und in der objektorientierten Programmierung Methoden von Klassen) kommt dabei eine besondere Bedeutung zu: Funktionen sind die erste Ebene der Organisation in jedem Programm.

Um hilfreich für die Übersichtlichkeit und Beherrschbarkeit eines Programms zu sein, müssen Funktionen eine Reihe von Eigenschaften erfüllen: Sie müssen kurz sein, weil nur kurze Funktionen von Menschen in ihrer Gänze erfasst werden können. Funktionen sollten genau eine Sache tun, die dafür aber richtig – das Unix-Prinzip „Do one thing, and do it well“. Innerhalb einer Funktion sollte möglichst eine Abstraktionsebene vorherrschen, da sie sonst schnell schwer verständlich und unnötig lang wird. Schließlich sollten Funktionen so wenige Parameter wie möglich haben. Der Idealfall von Funktionen ohne Parametern ist fast nur in der objektorientierten Programmierung erreichbar, da aber der Regelfall, weil das Objekt bzw. die Klasse den notwendigen Kontext bereitstellt. Wo immer möglich sollte die Reihenfolge mehrerer Parameter aus dem Funktionsnamen eindeutig hervorgehen.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, es werden aber keine Antworten zur Verfügung gestellt.

• Welche Gründe gibt es, Funktionen möglichst kurz zu halten?
• Wie lässt sich feststellen, ob eine Funktion mehr als eine Aufgabe erfüllt?
• Was sind Nebenwirkungen und warum sollte man sie auf jeden Fall vermeiden?
• Was ist das Problem zu vieler Parameter einer Funktion? Wie lässt es sich umgehen?
• Mit welchen Argumenten lässt sich das Schreiben modularen Codes motivieren?

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Funktionen sind ein wesentlicher Aspekt von sauberem und lesbarem Code. Entsprechend prominient wird die Thematik von Robert C. Martin in seinem Buch „Clean Code“ [Martin, 2008Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey] und dort in Kapitel 3 behandelt.

Weitere gute Hinweise finden sich in Kapitel 7 in [McConnell, 2004McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington].

Ein sehr lesenswertes Buch ist „The Art of UNIX Programming“ von Eric S. Raymond [Raymond, 2004Raymond, Eric S. (2004): The Art of UNIX Programming, Addison Wesley, Boston]. Hier findet der geneigte Leser sehr viele Beispiele und eine solide Einführung in die Grundprinzipien von UNIX, neben vielen Tipps für wirklich modulare Programme.

• Martin, Robert C. (2008): Clean Code. A Handbook of Agile Software Craftmanship, Prentice Hall, Upper Saddle River, New Jersey
• McConnell, Steve (2004): Code Complete. A practical handbook of software construction, Microsoft Press, Redmond, Washington
• Raymond, Eric S. (2004): The Art of UNIX Programming, Addison Wesley, Boston