In the Code: Sauber und elegant Code schreiben

Die Analogien und Unterschiede zwischen gutem Code und Deutschaufsätzen beschreibt Ergon-CTO Erich Oswald in sauberem Deutsch und in Clean Code.
 
Wer ab und zu einem Softwareentwickler über die Schulter blickt, stellt fest, dass der Arbeitsschritt, den wir als "Programmieren" bezeichnen, zu einem grossen Teil darin besteht, Text zu schreiben. In erster Linie adressieren wir dabei den Computer, der diesen Text als Code interpretieren wird. Der Code muss den strengen Regeln folgen, die uns die Grammatik der gewählten Programmiersprache auferlegt. Darüber hinaus stellt der Computer aber keine Ansprüche. Dies zeigt sich an Wettbewerben wie dem "International Obfuscated C Code Contest". Bei diesem geht es darum, ein kleines Programm so zu formatieren und zu verstümmeln, dass man ihm möglichst nicht ansieht, was es bewirkt, wenn man es ausführt. (Wer würde schon vermuten, dass ein in Form des Buchstaben "Pi" formatiertes Programm mit vielen Sequenzen der Form "3_1415" die Zahl e ausdruckt).
 
In der Praxis streben wir allerdings nach dem Gegenteil und versuchen, den Code so verständlich und nachvollziehbar wie möglich zu formulieren. Professionelle Softwareentwicklung ist Teamarbeit und erfordert, dass alle Personen im Team den Code lesen, verstehen und anpassen können. Die korrekte Interpretation des Programms durch die Maschine allein ist dafür kein Massstab. Je weniger Zeit Entwickler benötigen, um sich in ein Stück Code einzuarbeiten, desto schneller können sie ein Programm um neue Funktionen erweitern und desto kleiner ist das Risiko, dass sie dabei versehentlich Fehler einbauen.
 
Für diese Bemühungen hat sich in den letzten Jahren der Begriff "Clean Code" aus dem gleichnamigen Buch von Robert C. Martin eingebürgert. Sauberer Code ist seither zu einem Kernthema für die Bewegung der "Software Craftsmanship" geworden. Diese verfolgt eine Vision von professioneller Softwareentwicklung, die sich stark an den handwerklichen Fähigkeiten und dem Ehrenkodex der Programmierer orientiert. Die Idee ist allerdings nicht neu: Bereits 1974 publizierten die Unix-Autoren Brian W. Kernighan und P. J. Plauger ein Buch namens „The Elements of Programming Style“ für das elegante Schreiben von C-Programmen. Die Anlehnung an "The Elements of Style", eine Anleitung für gutes Schreiben von amerikanischem Englisch („one of the 100 best and most influential books“ gemäss New York Times), ist durchaus absichtlich.
 
Von Programmierern verfasste Dokumentation lässt einen leider ab und zu zweifeln, ob diese wirklich für menschliche Leser geschrieben wurde. Es mag überraschen, aber gute Softwareentwickler sollten idealerweise auch über Fähigkeiten verfügen, die eher mit dem Schreiben von Deutschaufsätzen als mit Mathematikprüfungen zu tun haben.
 
Im Sprachunterricht lernen wir beispielsweise, dass Sätze mit vielen verschachtelten Nebensätzen für den Leser schwer verständlich und komplex sind. Dasselbe gilt für Code:
 
Wir begrenzen die Schachtelungstiefe von Programmkonstrukten wie Bedingungen und Schleifen auf wenige Ebenen. Ähnlich wie wir in Artikeln ellenlange Abschnitte und Bleiwüsten vermeiden, halten wir auch beim Programmieren einzelne Funktionen und Methoden kurz und überschaubar. Und genau so, wie wir einen Text gliedern, um den Gedankenfluss des Lesers zu steuern, organisieren wir auch Programmfunktionen als einzelne, logisch schlüssige Abschnitte, die in unmittelbarer Nähe zueinander stehen und sich aufeinander beziehen. Die Namen der Funktionen und Methoden übernehmen dabei die Rolle von Zwischentiteln. Spezielle Werkzeuge zur statischen Codeanalyse können Programmierer dabei unterstützen, den Code übersichtlich zu gestalten. Diese ermitteln dazu Metriken wie zyklomatische Komplexität, Methodenlänge und LCOM4 ("low cohesion of methods") und bemängeln ab einem gewissen Schwellenwert, dass der Code schlecht organisiert ist und zu komplex wird. Ohne ein Minimum an Disziplin und Einfühlungsvermögen in den Leser nützen allerdings die besten Werkzeuge nichts.
 
Neben diesen Analogien zwischen Code und normalen Texten lassen sich natürlich auch etliche Unterschiede ausmachen. Schon das Vokabular und die Formatierung von Code sind speziell. Es handelt sich weniger um Prosa als um eine sonderbare Form der Poesie, die der formalen Grammatik der Programmiersprache anstatt den Regeln von Versmass und Reimen folgt. Beim Code haben wir zudem nie die Absicht, dessen Wirkung auf den Leser mit rhetorischen Figuren zu verstärken. Im Gegenteil: Eine Definition von sauberem Code ist, dass er möglichst keine Überraschungen für den Leser enthalten soll. Mag uns eine Lehrperson im Aufsatz anstreichen, dass wir ständig dasselbe Wort für einen Begriff verwenden: im Code bemühen wir uns, für dasselbe Ding konsistent denselben Namen zu verwenden und Synonyme zu vermeiden. Hingegen sind unnötige, redundante und repetitive Wiederholungen identischer Abläufe im Programm verwirrend und gelten als Wartungsfallen. Auffälligkeiten und Ausfälligkeiten sind unerwünscht. Je langweiliger, desto besser!
 
Die Analogien zwischen Code und Poesie sind ein Beispiel dafür, welch zentrale Rolle die Kommunikation in der Softwareentwicklung spielt. Kommunikation mit Anwendern, Auftraggebern, Betreibern, Teamkollegen und nicht zuletzt mit der Maschine ist ein essentieller Bestandteil der täglichen Arbeit, gehorcht aber ganz unterschiedlichen Spielregeln. Im Fall von Programmcode muss derselbe Text sogar mehrere unterschiedliche Adressaten bedienen, die Menschen _und_ die Maschine. Diese Vielfalt macht den Job spannend und anspruchsvoll, kann aber auch frustrieren: Wenn die Maschine den Code korrekt versteht, ist die Arbeit doch grundsätzlich getan? Schliesslich ist dadurch die Anforderung des Kunden ja erfüllt! Mehr Zeit zu investieren, damit andere Menschen den Code auch künftig schneller und besser verstehen, gilt darum schnell als unnötige Verschwendung und "Vergolden". Ein kompletter Verzicht ist allerdings riskant und führt vermutlich zu höheren Fehlerquoten und steigendem Wartungsaufwand. Es ist die gemeinsame Aufgabe von Entwicklern und Management, dafür die richtige Balance zu finden.
 
In diesem Sinne: Ich habe Lust aufs Programmieren bekommen und gehe dann mal wieder Kuchencode (statt Spaghetticocde) schreiben.
 
Unaufgeräumter und sauberer Code am Beispiel Kuchenbacken (PDF)
 
Über den Autor
Erich Oswald ist Chief Technology Officer beim Zürcher Softwarehersteller Ergon. Zu seinen Aufgaben gehören neben der alltäglichen Entwicklung seit über zehn Jahren die Pflege des Technologieportfolios im Bereich von Java SE und Java EE sowie die Beratung von Kunden und Teams beim Einsatz von Technologie, Softwarearchitektur und agilen Entwicklungsmethoden. Erich Oswald hat seine Studien an der ETH Zürich mit einem Diplom in Informatik und einem Doktor der technischen Wissenschaften abgeschlossen.