Clean Code: Ehrensache oder Overengineering?

Stell Dir mal vor, Du bist neu im Job – ein aufstrebendes IT-Talent, das alles richtig machen will, und es läuft soweit auch super – bis Deine Vorgesetzte Dich bittet, ein neues Feature zu programmieren und Du einen Blick auf den bestehenden Code wirfst. Dö-döm: der Scheideweg für alle Programmierer:innen. Was wirst Du antreffen? Stößt Du auf Clean Code, an den sich super anknüpfen lässt oder öffnest Du das Tor zur Hölle? Der Entwickler Michael Feathers hat es so ausgedrückt:

Umgekehrt gibt es Code, den man gar nicht mehr anfassen will, aus Angst, bei der kleinsten Veränderung alles kaputt zu machen und massive Schäden anzurichten. Das spricht dafür, dass hier das Gegenteil von Clean Code im Spiel ist: Bad Code.

Bei kleinen Projekten fällt Bad Code oft gar nicht auf, und es macht auch nichts, dass er unsauber ist, das Ding läuft trotzdem. Doch je komplexer ein Projekt wird, je mehr Du verändern oder nachträglich hinzufügen möchtest, desto stärker bist Du und alle Entwickler:innen vor und nach Dir auf Clean Code angewiesen. Aber: 

Clean Code muss ein paar Bedingungen erfüllen: Er muss

• gut lesbar
• verständlich
• logisch
• veränderbar
• erweiterbar und
• wartbar 
   

sein. Er sollte Comments enthalten, wenig Abstraktionen besitzen und schlanke, möglichst kurze Functions aufweisen. Je mehr if-Verzweigungen, desto komplizierter und am Ende schwierig nachvollziehbar wird Dein Code. Klassen sollten ebenso korrekt verwendet werden wie Namensregeln, White Spaces usw. Kennst Du das, wenn Du alten Code von Dir anschaust, den Du vor einem halben Jahr – oder sogar wenigen Wochen – geschrieben hast und Du denkst Dir: Was macht das noch mal genau? Das ist meist ein Zeichen dafür, dass Du den wichtigen allerersten Schritt nicht ausreichend beherzigt hast:

Ist die Function wirklich logisch? Ist sie so schlank, wie sie nur sein kann? Wie könnte man noch mehr Zeilen sparen? Und vor allem: Wie schreibe ich den Code so, dass die Nachwelt ihn problemlos versteht? Dir diese Fragen zu stellen, ist schon mal ein guter Start.

Beispiel (php): Bad Code vs. Clean Code

In der ausführlichen Variante funktioniert der Code zwar auch, aber nach der Spracherweiterung passt alles auch in einen Einzeiler:

Im Informatikstudium geht es vor allem darum, sich dem Programmieren anzunähern und ein spezifisches Problem zu lösen. Deshalb wird auch nicht allzu viel Wert oder Gewicht auf sauberen Code gelegt. Erfüllt er seinen Zweck, ist er in der Regel gut genug. Es muss ja auch später selten noch jemand etwas damit anfangen können. Im Berufsleben ist das anders: Hier baut ein ganzes System darauf auf, das im Idealfall anpassungsfähig und flexibel ist. 

4 Grundwerte für Clean Code

• Wandelbarkeit
   
• Korrektheit
   
• Produktionseffizienz und
   
• kontinuierliche Verbesserung
   

Das heißt, Dein Code muss verändert werden können, und zwar nicht mühselig, denn das macht ihn teuer und ineffizient, sondern einfach als wärst Du “someone who cares”: Reflektiere Deinen Code. Fallen Dir kleine Verbesserungen auf, mache Dich direkt dran und setze sie um. Gehe größeren Issues geflissentlich nach. Bilde Dich weiter. Und vor allem: Betreibe ordentliches Versionsmanagement! 

Beispiel (php): Komplizierte Lösung vs. verständliche Lösung

Die erste Version ist wegen der 3 Conditions und 2 Negations schwierig zu verstehen.

In einem solchen Fall hilft es z.B., wenn Du Bedingungen extrahierst, um Conditions besser verständlich zu machen oder Negations in True Conditions umwandelst. Das Early Return Pattern solltest Du ebenfalls verwenden: 

Es gibt eine große Bandbreite an Tools, die Dir helfen, dem Ideal des Clean Code näher zu kommen und die Dir zum Beispiel sagen, wenn Deine Function zu komplex oder Deine Klasse zu groß ist. Mit Linting und Tools wie CodeSniffer sorgst Du dafür, dass Dein Code immer die gleiche Formatierung hat, Syntaxfehler behoben werden und er insgesamt besser lesbar ist. Tools für statische Analysen geben Dir Auskunft über die Komplexität Deiner Zeilen – sei sparsam mit “ifs”! MessDetectors analysieren Deinen Code nach Altlasten wie unbenutzten Variablen oder unerreichbare Code-Abschnitte. Stößt Du so auf “Copy-Paste”-Code, kannst Du davon ausgehen, dass schnell eine Lösung her musste, als das entstanden ist. Viele dieser nützlichen Tools sind heute sogar in den IDEs integriert, zum Beispiel CodeInspection auf PhpStorm. 

There’s no view like a review

Auch Unit Tests gehören dazu, wenn Du Clean Code produzieren möchtest. Die laufen automatisiert und sorgen dafür, dass Du in der Live-Umgebung nichts kaputt machst, während Du bastelst. Am meisten aber lernst Du vermutlich durch das gute alte Code Review. Denn hier geht es explizit darum, bestehenden Code auf Mängel zu untersuchen und ihn zu refactoren, d.h. ihn zu verbessern, ohne das Funktionsspektrum zu schmälern. Oft geschieht das im Rahmen des agilen Pair oder Extreme Programmings (XP) und Du hast noch eine Person an Deiner Seite, die sich auch auskennt, ein weiteres kritisches Augenpaar und ihre Gedanken beisteuert. Ihr Feedback wird Dir auch für die nächsten Male nützlich sein. Denn das ist das Schöne an der Dev-Community: Ihr arbeitet gemeinsam an genialem Code, nicht gegeneinander. Also teile auch Dein Wissen, wann immer möglich!

Prinzipien für besseren Code

Du siehst schon: Es geht beim Coden keinesfalls darum, perfekt zu sein – Fehler oder Dinge, die man hätte besser machen können, sind völlig normal. Wichtig ist, die Einstellung zu haben, immer besser werden zu wollen und dafür auch bereit zu sein, unbequeme Strecken zu gehen. Dabei helfen Dir ein paar zentrale Prinzipien:

Am Ende läuft sauberer Code immer wieder aufs selbe hinaus: Er ist schlank, einfach und gut lesbar. Für professionelle Programmierer:innen ist es Ehrensache, dass sie den Clean Code Paradigmen folgen. Wie Robert C. Martin, der "Gottvater" des Clean Code, erklärt: 

Sein Werk “Clean Code: A Handbook of Agile Software Craftsmanship” ist gerade für Einsteiger:innen wirklich empfehlenswert, weil einem klar wird, dass man sich lieber einmal die Mühe macht, nachzudenken und sauber zu schreiben als im Nachhinein Rollschuh-Mikado auf Eierschalen spielen zu müssen. Eine besondere Herausforderung ist das natürlich, wenn Du auf einen Haufen Bad Legacy Code stößt. Aber manche Leute können sich wunderbar für Refactoring begeistern und spezialisieren sich ganz gezielt darauf. So zum Beispiel auch Dustin Boswell, dessen Werk “The Art of Readable Code” wir Dir ebenfalls ans Herz legen möchten. Er hält es wie “Uncle Bob” Martin, wenn er sagt:

Also, vergiss nie Deine Verantwortung als Programmierer:in – es wird jemand nach Dir kommen (im Zweifel Du selbst...). Clean Code ist für Profis einfach Ehrensache und für Berufseinsteiger ein klarer Vorteil im Bewerbungsprozess, wenn Du Dich mit den Prinzipien schon befasst hast und weißt, worauf es ankommt.