Mithilfe der Prinzipien von Clean Code verbessern Sie die Lesbarkeit Ihrer selbst entwickelten Programme und helfen nicht nur anderen Entwicklern, den Quelltext zu verstehen, sondern auch sich selbst.
Bei Clean Code handelt es sich um eine Reihe von Regeln und Verfahren, die es erleichtern, Quellcode zu lesen und zu verstehen. Dabei ist es unerheblich, welche Programmiersprache zum Einsatz kommt. Viele Konzepte von Clean Code passen auf alle Sprachen. Einige weiterreichende Konzepte erweisen sich allerdings nur im Umfeld der objektorientierten Sprachen als sinnvoll. Der Clean-Code-Gedanke ist an sich nichts Neues und Revolutionäres. Schon 2008 hat Robert C. Martin in seinem Buch die Verfahren beschrieben [1].
Allerdings wird es bei den heute üblichen hochkomplexen IT-Anwendungen immer wichtiger, auf eine saubere Struktur des Source-Codes zu achten. Zudem hat sich der Clean-Code-Gedanke in den letzten Jahren weiterentwickelt, und die im Buch beschriebenen Verfahren wurden erweitert. Lassen Sie uns also die Reise in eine Welt mit sauberem Quellcode beginnen. In den folgenden Absätzen beschreiben wir einige der Kerngedanken und Regeln von Clean Code.
Pfadfinderregel
“Hinterlasse Code immer sauberer, als du ihn vorgefunden hast.” Wenn man diese Regel beherzigt, wird der Quellcode eines Projekts mit der Zeit immer besser. Man muss auch keine Angst haben, etwas kaputtzumachen, weil sich über die Versionsverwaltung (zum Beispiel Git) der alte Zustand immer wiederherstellen lässt. Moderne IDEs stellen zudem viele Tools zum Reengineering von Code bereit. So ist das Umbenennen von Klassen oder Methoden gar nicht mehr so riskant.
Üblicherweise spielt es für den Compiler keine große Rolle, wie der Entwickler die einzelnen Programmbestandteile benennt. Ob Groß- oder Kleinschreibung, ob Unterstrich oder Camel Case: Solange es nur irgendwie zusammenpasst, wird ein lauffähiges Programm daraus gebaut. Allerdings lässt sich ein solcher Code extrem schwer lesen. Halten Sie sich also besser an die für die Programmiersprache geltenden Vereinbarungen.
In Java zum Beispiel sollten Klassennamen immer mit einem Großbuchstaben beginnen, Methoden hingegen mit einem Kleinbuchstaben. Moderne IDEs haben üblicherweise eine Funktion, um Source-Code automatisch zu formatieren – diese sollten Sie auf jeden Fall nutzen. Arbeiten mehrere Personen an einem Projekt, sollten sich alle auf dasselbe Format einigen.
Sprechende Namen
Es sollte eigentlich für jeden Entwickler selbstverständlich sein, dass man den Bestandteilen, aus denen ein Programm aufgebaut ist, am besten sprechende Namen gibt. Hiermit sind die Klassen, Methoden beziehungsweise Funktionen und Variablen gemeint. Die Namen sollen nicht zu lang ausfallen, aber trotzdem präzise beschreiben, worum es geht. Hierbei sollte man auch den Gültigkeitsbereich der Variablen im Auge behalten.
Es ist vollkommen in Ordnung, die Schleifenvariablen wie gewohnt mit i oder j zu benennen. Bei einem Koordinatensystem sind x, y und z sicher die aussagekräftigsten Bezeichnungen. Wird eine Variable oder ein Objekt in einem größeren Kontext verwendet, sollte man sich durchaus über den Namen ein paar Gedanken machen. Vermeiden Sie es, den Klassennamen mit in die Methodennamen aufzunehmen.
Dass eine Methode immer auf dem Objekt arbeitet, in dem sie definiert ist, sollte jedem klar sein. Verwenden Sie als Klassennamen immer Substantive, weil diese die Entitäten repräsentieren. Methodennamen hingegen sollten Verben beinhalten. Idealerweise verwenden Sie keine Abkürzungen im Namen; Ausnahmen bestätigen hier die Regel (zum Beispiel MwSt).
Es klingt vielleicht erst einmal eigentümlich, aber achten Sie darauf, dass Namen aussprechbar sind. Es kommt immer wieder vor, dass in einem Meeting oder Code-Review über eine Klasse geredet wird. Dann hilft es, keine zu komplexen oder sehr ähnlich klingenden Namen zu haben.
Global sollte es nie nötig sein, mit einem Kommentar zu erklären, welchem Zweck eine Komponente dient. Ihr Name sollte vielmehr für sich selbst sprechen. Verwenden Sie daher keine nichtssagenden generischen Namen wie Manager, Helper, Handler, Processor und so weiter. Eine Klasse ist immer für einen konkreten Zweck gedacht, also benennen Sie diesen auch. Bei Kundenprojekten sollten Sie für die Namensgebung die Bezeichnungen des Kunden verwenden, sonst kommt es immer wieder zu Missverständnissen.
Wählen Sie Namen so, dass sie das Konzept, die Verantwortung und auch die Abgrenzung aufzeigen. Ein Beispiel: Verwenden Sie das MVC-Konzept, dann benennen Sie die Klassen als Model, View und Controller. Bauen Sie zusätzlich auch die konkrete Funktion mit in den Namen ein, beispielsweise LoginController oder ContractSaveController.
Typenbezeichnungen haben nichts in Methoden- und Variablennamen zu suchen. Schreiben Sie also nicht List customerList = getCustomerList, sondern List customers = getCustomers. Man erkennt bereits am Typ, dass es sich um eine Liste handelt. Außerdem sollten Sie für eine Entität (etwa Login, User oder Account) immer denselben Namen verwenden. Füllworter wie to, from und Ähnliches gilt es zu vermeiden.
Kommentare
“Wenn der Compiler den Code versteht, muss das der Entwickler auch tun. Daher sind Kommentare unnötig.” Diese auf den ersten Blick etwas kurzsichtig erscheinende Aussage ergibt in leicht abgewandelter Form im Clean-Code-Kontext durchaus Sinn. Haben Sie das Gefühl, eine Programmstelle mit einem Kommentar versehen zu müssen, sollten Sie noch einmal darüber nachdenken, ob der Code wirklich sauber ist. Dasselbe gilt für die Namen von Klassen, Methoden und Variablen.
