Code, einfach und verständlich Clean-Code-Prinzipien richtig anwenden

Software sollte so programmiert werden, dass der Code auch von Dritten gut verstanden wird und sauber arbeitet. Dabei helfen die Clean Code Principles. Diese gehen allerdings auch mit Nachteilen einher.

Jeder Entwickler weiß: Es gibt guten und schlechten Code. Allerdings gibt es zwei Formen von „schlechtem“ Code: Solcher, der einfach schlecht funktioniert – und solcher, der schlecht strukturiert und verworren ist, ohne dass er funktional problematisch wäre.

Gerade letzterer ist aber dann problematisch, wenn es darum geht, ein Software-Projekt zu übertragen – sei es im Rahmen agiler Entwicklung, oder weil das Entwickler-Team wechselt, umstrukturiert oder sich vergrößert. Es kann aber auch sein, dass die Software als Open-Source-Projekt veröffentlich werden soll. In all diesen Fällen ist es sinnvoll, dass der Code „sauber“, also möglichst umstandslos lesbar ist.

Seit geraumer Zeit existieren Ideale der Software-Entwicklung, die genau das einfordern: Prinzipien wie KISS, DRY oder YAGNI sind schon lange formuliert, um Entwickler dazu anzuhalten, Code möglichst sauber, von anderen Entwicklern nachvollziehbar und minimalistisch zu gestalten.

KISS („Keep it simple, stupid“)

Das KISS-Prinzip ist eines der ältesten Prinzipien der Software-Entwicklung und wurde schon in den 1960ern vom US-Militär etabliert. Dinge sollten einfach sein, das schließt neben Bedienung und dem Einsatzzweck im Falle von Software auch die Codebasis ein. Das bedeutet für Entwickler, dass sie ihren Code und die verwendete Programmiersprache jederzeit hinterfragen sollten. Gibt es einen einfacheren Weg, um das Problem zu lösen? Dann nimm ihn.

DRY („Don’t repeat yourself“)

Das DRY-Prinzip ist ebenfalls sinnvoll, um Code einfach zu halten: Es geht darum, dass Dinge nicht mehrfach „abgefrühstückt“ werden sollen. Wenn zum Beispiel ein Wert ausgelesen und später verwendet werden soll, ist es sinnvoller, eine Funktion zu entwickeln, die den Wert zwischenspeichert, statt ihn zweimal auszulesen. Der DRY-Code ist dabei ausgefeilter als der Nicht-optimierte „WET-Code“ („We enjoy typing“): Zwar mag die einzelne Funktion dadurch länger werden, am Ende des Tages bleibt es aber höchstwahrscheinlich bei deutlich weniger Code und damit Rechenzeit.

YAGNI („You Aren't Gonna Need It“)

Das YAGNI-Prinzip besagt, dass zunächst jeder zusätzliche Code überflüssig ist: Er sollte nur hinzugefügt werden, wenn es dafür einen berechtigten Grund gibt, etwa das Hinzufügen einer neuen Funktion. Dabei gibt es gewisse Überschneidungen mit KISS und DRY: Wenn sich eine Funktion innerhalb einer anderen lösen lässt, greift sowohl KISS, als auch DRY und YAGNI, denn es ist keine „überflüssige“ Code-Zeile notwendig. Code, der keinen spezifischen Zweck (mehr) hat, sollte dementsprechend entfernt (und nicht bloß auskommentiert) werden.

Alle drei Prinzipien sorgen bei Anwendung mehr oder weniger automatisch dafür, dass Code sauberer, also „cleaner“ wird. Allerdings muss das nicht zwingend der Fall sein, etwa wenn KISS, DRY und YAGNI angewandt werden, der Code aber dennoch ein chaotisches Konstrukt ist.

Hier kommen die Clean Code Principles ins Spiel, eine detailliert aufgeschlüsselte Liste zur Reinhaltung von Code, die Entwickler Robert C. Martin 2009 in seinem Buch „Clean Code“ festgehalten hat. Backend-Engineer Wojtek Lukaszuk hat die Essenz des Buches sehr detailliert auf GitHub zusammengestellt.

Ergänzungen zur traditionellen Clean-Code-Philosophie

Die Clean-Code-Principles von Martin sind gegenüber den „klassischen“ drei Prinzipien deutlich erweitert. Er schlüsselt die Regeln zudem für Design, Verständlichkeit, Funktionalität, Kommentierung und viele andere Bereiche auf. Das kann Entwicklern – egal ob Front- oder Backend – dabei helfen, ihren Code von Grund auf sauber und lesbar zu konzipieren.

Wichtige Best-Practices wie das Einhalten von Konventionen oder das Trennen von Multi-Threading-Code, der Hinweis, sich an eigene Regeln – Stichwort Konsistenz – zu halten und bei der Kommentierung nicht redundant zu werden, sind Infos, die die meisten Programmierer sicher bereits gehört haben oder anwenden. Allerdings fallen sie im Alltag dann doch auch oft unter den Tisch, sei es aus Zeitdruck, Nachlässigkeit oder aus ineffizienter Teamarbeit heraus.

Martins umfangreiche Liste von Clean-Code-Prinzipien lässt sich allerdings auf sechs sehr solide Basis-Regeln herunterbrechen:

• Sorge für klare Struktur bei und zwischen Funktion, Daten und Design.

• Befolge Konventionen.

• Trenne Funktionen.

• Vermeide Wiederholungen.

• Kommentiere so oft wie nötig und so wenig wie möglich.

• Halte Code so klein und einfach wie möglich.

Kurzum: Der Code sollte keine unnötigen Schnörkel aufweisen und für Dritte gut nachvollziehbar bleiben. Auf diese Weise ist es für neu hinzukommende oder übernehmende Entwickler leicht, eine vorhandene Code-Basis zu verwenden, zu ergänzen oder zu optimieren, selbst wenn der ursprüngliche Entwickler längst an anderen Projekten arbeitet oder das Unternehmen verlassen hat. Sauberer Code garantiert, dass andere Entwickler möglichst reibungslos übernehmen können, was Reibungsverluste reduziert, Kosten spart – und am Ende natürlich auch für bessere Software-Qualität sorgt.

Gerade langfristige oder lange in Betrieb bleibende Software-Projekte – etwa Software für Industrie und Produktion – , aber auch aufwändige, von mehreren Entwicklern oder sogar Teams gepflegte Software wie etwa die großen Open-Source-Projekte profitieren daher in der Regel von der Einhaltung der Clean-Code-Princples, egal ob klassisch oder nach Robert C. Martin.

Clean Code ist nicht immer der beste Code

Bei strenger Einhaltung der Clean-Code-Prinzipien gibt es allerdings ein Problem: Der sauberste Code ist nicht immer der beste, wie Spieleentwickler Casey Muratori in einem interessanten Youtube-Video nachgewiesen hat. Hier testete er „Clean Code“ gegen die nicht ganz so saubere Variante, nämlich polymorphen Code gegenüber konditionellen Funktionen vorzuziehen.

Trotz der saubereren Code-Struktur kam es hier mit der „klassischen“ Methode zu einer rund 50 Prozent besseren Leistung – auch weil die für den Polymorphismus benötigten Extras nicht eingebunden werden müssen. Casey Muratori: „Da werden drei oder vier Jahre Hardware-Evolution ausgelöscht, weil jemand gesagt hat, Polymorphismus wäre Switch-Statements vorzuzuziehen.“

Natürlich hängt es stark mit der Anwendung des Codes zusammen, ob dieser Einbruch tatsächlich in diesem Ausmaß stattfindet. Und natürlich sind auch „Mischformen“, die nur teilweise die Clean-Code-Prinzipien umsetzen, denkbar. Am Ende des Tages gilt es für Entwickler, ein funktionierendes Mittelmaß aus sauberem Code und effizienter Hardware-Nutzung zu finden.

(ID:49865805)