# Funktionen Funktionen sind die grundlegendste Komponente, die ein Programm ausmachen. So ist es wichtig, gute Funktionen schreiben zu können. Auf was dabei geachtet werden muss, will ich in diesem Blog angehen. ## Goldene Regeln ### 1. Je kleiner desto besser Die wahrscheinlich wichtigste aller Regeln ist diese: Funktionen sollten möglichst klein sein! Wie kurz sollte eine Funktion jedoch sein? Ein guter Messwert ist, maximal 20 Zeilen zu erlauben. Idealerweise sind sie aber noch kürzer. Wie genau eine solche Funktion aufgebaut wird werde ich in den folgenden Regeln ansprechen. ### 2. Nur eine Aufgabe pro Funktion Es gibt einen Rat der bereits seit 30 Jahren neuen Entwicklern gelehrt wird: > "Funktionen sollten eine Aufgabe erledigen. Sie sollten sie gut erledigen. Sie sollten nur diese Aufgabe erledigen." Aber was zählt als eine Aufgabe? Manchmal ist es schwierig abzuschätzen, ob eine mehrzeilige Funktion nur eine oder mehrere Aufgaben umfasst. Grundsätzlich wird mit Aufgabe eine Abstraktionsebene gemeint. Mit einem TO-Absatz (UM-ZU-Absatz) können wir eine Funktion beschrieben. Dies macht es einfacher zu sehen welche Aufgaben eine Funktion erfüllt. Angenommen wir haben eine Funktion namens ValidateAndSubmitForm: ``` TO ValidateAndSubmitForm, validieren wir zuerst die Email und das Passwort auf. Falls beide gültig sind, reichen wir das Formular ein. ``` In dieser Funktion sehen wir jetzt weitere Funktionen welche wiederum mit einem TO-Absatz beschrieben werden können. ### 3. Gleiche Abstraktionsebene Wenn wir uns an die obige Regel halten und unsere Funktion nur eine Aufgabe erledigt, dann müssen sich alle Anweisungen innerhalb dieser auf der gleichen Abstraktionsebene befinden. Das mischen von Abstraktionsebenen innerhalb einer Funktion ist in jedem Fall verwirrend. Ausserdem sollten die Funktionen innerhalb des Programms nach Abstraktionsebene sortiert werden. So kann man die Abfolge von Funktionen als eine Reihe von UM-ZU Sätzen gelesen werden. ### 4. Beschreibende Namenswahl Ich werde in diesem Blog nicht tiefer auf die Regeln der Namensgebung eingehen. Dafür habe ich bereits einen eigenen Artikel verfasst: Kapitel [[1. Namensgebung]]. Jedoch will ich auch hier noch einmal unterstreichen wie wichtig die Namensgebung ist. Ein guter Name kann der entscheidende Faktor zwischen gutem und schlechtem Code sein. ### 5. Funktionsargumente Die Anzahl an Argumenten in einer Funktion ist kritisch für die Sauberkeit. Es ist naheliegend, dass weniger Argumente besser sind, aber wie viele sind Optimal? Natürlich sind 0 Argumente (*niladische Funktion*) am optimalsten. Dies ist jedoch in vielen Anwendungsfällen nicht realistisch und es wird mindestens 1 Argument (*monadische Funktion*) benötigt. Auch 2 Argumente (*dyadische Funktion*) ist kein Problem. 3 Argumente (*triadische Funktion*) sollten, wenn immer Möglich, vermieden werden und alles darüber (*polyadische Funktion*) wird ist nur in Ausnahmefällen akzeptabel. Dies ist auch aus der Sicht eines Testers wichtig. Schon bei zwei Argumenten ist es schwieriger alle Möglichkeiten mit Tests abzudecken. Die obig genannten Regeln beziehen sich auf Input-Argumente. Output-Argumente sollten eigentlich nie verwendet werden. Auch Flag-Argumente (boolesche Argumente) sollten weggelassen werden. Stattdessen sollte in zwei Funktionen aufgeteilt werden. ### 6. Funktionen sollten nicht Lügen Keine Funktion sollte etwas versprechen und anschliessend etwas weiteres verborgenes erledigen. Es ist wichtig, dass wirklich nur eine Aufgabe pro Funktion aufgeführt wird und diese Aufgabe auch vollumfänglich angegeben wird. ## Wie halte ich diese Regeln ein? Ein Programm zu entwickeln ist wie das Schreiben eines Aufsatzes; Zuerst muss geplant und ein grober Überblick geschaffen werden. Es ist selten, dass eine Funktion perfekt ist bei der ersten Version. Stattdessen ist es völlig normal wenn eine Funktion zuerst keine dieser Regeln befolgt. Die Regeln können dann im zweiten Schritt beachtet werden, wenn die Funktion aufgeteilt und umstrukturiert wird.