Fünf einfache Wege, um sofort besseren Code zu schreiben

Über »Clean Code«, den Weg besseren Programmcode zu schreiben, gibt es viel Literatur. Oft sind die Bücher leider von einem Umfang, der auf Einsteiger abschreckend und nicht motivierend wirkt. Glücklicherweise muss man selten komplette Bücher lesen, um die eigenen Fähigkeiten zu verbessern. Bereits für Einsteiger gibt es fünf einfache Wege, um sofort besseren Code zu schreiben.

1. Verwende beschreibende Namen für Variablen und Methoden

Variablen und Methoden gut zu benennen ist eine Kunst, die manche Entwickler erst sehr spät lernen. Besonders schwierig wird es, wenn sämtliche Bezeichner im Code in englischer Sprache sein sollen, man selbst mit dem Englischem aber wenig vertraut ist. Das kann zu sehr merkwürdigen Ergebnissen führen und der einzige Ausweg ist, die Sprache dann tatsächlich zu lernen. Gute Namen für Variablen und Methoden zu finden ist, damit verglichen, doch etwas einfacher.

Für Variablen und auch für Klassen sollten als Substantive als Namen verwendet werden. Einfach ausgedrückt, hat man es mit einer Sache, einem Ding, zu tun. Gute Beispiele sind Document, Person, Window, Button oder auch Application. Gelegentlich stößt man in der Praxis auf Namen wie Manager oder Controller. Diese Begriffe werden von vielen Entwicklern nicht gerne gesehen, weil sie eigentlich zu allgemein gehalten sind. Oft fehlt es auch zum richtigen Zeitpunkt an kreativen Ideen. Trotzdem sollte jeder Entwickler eine wage Vorstellung davon haben, welche Aufgabe ein WindowController hat.

Die Namen von Methoden und Funktionen sollten ein Verb sein oder mit einem Verb beginnen. Beispiele wären load, update, check, add, remove, show oder terminate. Zusammen mit den verwendeten Variablen ergeben sich dann leicht aussagekräftige Namen wie loadDocument oder showWindow.

Folgt man diesen Richtlinien, wird es leichter, im Code Methoden und Variablen zu unterscheiden. Außerdem kann an den Methodennamen erkannt werden, werden Art von Daten dort verarbeitet werden. Im Idealfall sollte es ausreichen, die Methodennamen zu lesen, um zu erkennen, was ein Programm kann und tut. Die Anweisung innerhalb einer Methode werden erst im zweiten Schritt interessant.

2. Halte Methoden und Funktionen kurz

Die Länge von Methoden und Funktionen ist ein Thema, über das viel diskutiert wird. Wie lang darf es denn sein? Die richtige Antwort ist schwer zu finden, aber Methoden mit mehreren dutzend Zeilen Programmcode gehören mit Sicherheit nicht dazu. Während in einigen Dokumentation eine Grenze von fünf Zeilen genannt wird, erfährt man anderswo von 15 Zeilen. Letzteres scheint mehr den Anforderungen der Realität zu entsprechen. Es ist ein Wert, der auch in der Praxis gut funktioniert.

Für einen Einsteiger ist es nicht immer leicht, kurze Methode zu schreiben. Diese Fähigkeit steigt mit der Erfahrung. Am Anfang genügt es, einer einfachen Richtlinie zu folgen: Eine Methode soll genau eine Aufgabe erfüllen und die soll sie gut erfüllen. Methoden, die mehrere Dinge tun, scheiden daher komplett aus. Daten laden, auswerten und anschließend anzeigen, das klingt schon in der Theorie nach vielen Zeilen Programmcode und die sollten nicht in einer einzelnen Methode stehen. Besser ist es, die Teilaufgaben auf mehrere Methoden zu verteilen und diese anschließend der Reihe nach abzuarbeiten. Das ist zunächst mehr Aufwand, aber der Code wird übersichtlicher und kann später leichter verändert werden.

3. Vermeide Abkürzungen für Variablen- und Methodennamen

Das Variablen oder Methoden nicht mit a, i oder x bezeichnet werden sollten, lernt man als Entwickler schon sehr früh. Aber auch längere Namen sorgen nicht zwangsläufig für eine bessere Lesbarkeit des Codes. Die Probleme beginnen, wenn es sich dabei um Abkürzungen handelt. Ein gutes Beispiel, das leicht zu Missverständnissen führen kann, ist die Bezeichnung min. Handelt es sich um das Minimum oder eine Minute? Auf Anhieb ist das nicht zu erkennen. Ohne Abkürzung wäre der Code leichter zu verstehen.

Abkürzungen zu vermeiden bedeutet nicht, komplett auf sie zu verzichten. Es gibt Abkürzungen, die weit genug verbreitet sind. Beispiele sind http oder ftp.

4. Sei sparsam mit Kommentaren

Die Aufforderung, weniger Kommentare zu verwenden, ist riskant. Die meisten Entwickler kommentieren ohnehin viel zu wenig. Trotzdem können zu viele Kommentare hinderlich sein. Sie geben leicht ein falsches Gefühl von Sicherheit, wenn man glaubt, die Kommentare würden eine Methode oder Klasse ausreichend erklären. Ein Projekt sollte auch ohne ausschweifende Erklärungen verständlich sein. Ist das nicht der Fall, stimmt etwas nicht mit dem Code. Zusätzlich schaffen Kommentare eine zusätzliche Belastung. Wird eine Methode geändert, muss auch der Kommentar angepasst werden. Vergisst man es, ist später die Verwirrung groß.

Grundsätzlich ist es gut, einer einfachen Richtlinie zu folgen: Ein Kommentar soll nicht erklären was passiert, sondern warum.

5. Du wirst es nicht brauchen

Eine Empfehlung für aufstrebende Softwareentwickler ist so weit verbreitet, dass sie im englischen Sprachraum sogar eine eigene Abkürzung hat: Y.A.G.N.I. (You ain’t gona need it). Einfach ausgedrückt geht es darum, nur Dinge zu programmieren, die tatsächlich benötigt werden. Nicht mehr.

Bei der Entwicklung gilt es immer, die aktuellen Anforderungen umzusetzen. Selbstverständlich können sich diese im Nachhinein ändern. Aber Methode oder Funktionen, von denen nur vermutet wird, dass sie irgendwann in Zukunft eventuell nützlich sein könnten, haben in einem Projekt nichts verloren. Sie kosten Zeit bei der Entwicklung und Dokumentation, bedürfen später eventuell Pflege, haben aber für die Software keinen Mehrwert, weil sie nicht zum Einsatz kommen. Diesen Aufwand sollte man an anderer Stelle sinnvoller investieren.

Geschrieben am: 30.06.2021
Technologien: Clean Code