Was zeichnet lesbaren Code aus?

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” – John F. Woods

Dieses Zitat deutet darauf hin, dass es bei Codestil und Art der Umsetzung wohl um ein emotionales Thema handelt. Entstanden vermutlich aus den Erfahrungen und Schmerzen, die man machte, als man versuchte, einen völlig vermurksten Code zu warten.

Um das zu verhindern, sieht man als Entwickler häufig Hinweise wie:

• Schreiben Sie guten Code.
• Strukturieren Sie sinnvoll.
• Schreiben Sie wartbare Programme.

An sich nicht falsch, aber man weiß trotzdem nicht, was man nun tun soll.
Es gibt Unmengen von Guidelines, Büchern und Anweisungen, wie man sinnvollen, lesbaren und vor allem wartbaren Code zu schreiben hat. Und alle haben irgendwie Recht, da es je nach Projekt, Personen, Sprachen, Branchen und Firmen völlig unterschiedliche Randbedingungen gibt. Die allgemeinste Hilfe ist vermutlich, "länger über den zu schreibenden und den geschriebenen Code sowie das Umfeld nachzudenken".

Für jeden allein ist es schon schlimm genug, seinen alten Code anzuschauen. Der eine oder andere wird sich schon über Codefragmente aufgeregt haben, nur um dann festzustellen, dass er sie vor Jahren selbst erstellt hat. Das ist völlig normal. Im Idealfall lernen wir schließlich ständig dazu und unsere Werkzeuge entwickeln sich stetig weiter.
So ist es also kein Wunder, dass wir manchen alten Code heute mit Fragezeichen im Kopf und "WTF" auf der Zunge anschauen, vor allem dann, wenn es noch nicht mal unser eigener Code ist.

Wenn ich guten Code lese, stellt sich relativ schnell ein gewisser "Wohlfühlfaktor" ein. Das ist meist dann der Fall, wenn man sich recht schnell zurechtfindet, die Benennungen im Code für den Kontext des Projektes sinnig sind und man im Code irgendwie nichts "Unerwartetes" findet. Auch ist es mir lieber, wenn Methoden etwas ausführlicher geschrieben sind, dafür aber nachvollziehbarer.
Eine kurze Methode mit kryptischen Anweisungen und möglicherweise Magic Numbers führt oft zu einem "Was?". Wenn dann noch helfende Kommentare fehlen, wird das schnell zum "WTF!".

Auf was sollte man jetzt beim Schreiben von Code achten?
Ausgehend von den obigen Indikatoren für einen Code mit "Wohlfühlfaktor", komme ich zu folgenden Punkten, auf die man schon bei der Erstellung von Code achten sollte.

Einheitliche Struktur

Sowohl der Code als auch die Projektstruktur sollten aufgeräumt sein. Keine wilden vereinzelten Dateien, die aus unterschiedlichsten Unterordnern womöglich noch eingebunden werden und gleichzeitig den Anschein erwecken, dass der Inhalt solcher Dateien lieber aufgeteilt und an andere Stellen verschoben werden wollte/sollte.
Codedateien sollten von der Struktur in etwa einheitlich sein. Das heißt, wenn ich mir eine Codedatei anschaue und eine andere, sollten allgemeine Dinge, wie Imports oder Includes an ähnlichen Stellen zu finden sein. Für Klassen und Methoden gilt das ebenso. Der Inhalt wird unterschiedlich sein, aber das "Bild" sollte ähnlich sein.
So eine Struktur erreicht man nur, wenn man die Zeit hat/bekommt/sich nimmt, um darüber nachzudenken, wie die Änderung ins gesamte Gefüge passt. Einfach nur fertig machen, ist hierfür zu wenig.

Sinnvolle Benennung

Alles, was einen Namen haben kann, sollte sinnvoll benannt werden. Sinnvoll bedeutet für mich, es sollte in die Domäne passen, keine inhaltslosen Namen, wie z. B. "FileA". Außerdem sollte der Name zu den restlichen im Code vorkommenden Bezeichnern passen. Ständiges Wechseln zwischen Methoden wie GetXY(), TakeAB(), YZ() bringen Unruhe ins "Bild".
Bei Variablen oder Methodennamen sollte beim Lesen schon klar sein, zu was diese da sind und was sie tun. Sollte sich ein Verhalten über die Zeit im Code ändern, dann bitte auch die Namen anpassen. Namen, die nichts mehr mit dem zu tun haben, was getan wird oder sogar das Gegenteil erahnen lassen, verwirren völlig.
Um das zu erreichen, ist es oft gut, mit einem Kollegen über die Benennungen zu sprechen. Häufig ergeben sich dabei interessante Standpunkte und Einblicke, wie ein solcher Name interpretiert wird.

Wenig Überraschungen

Hierbei meine ich Dinge, die nicht erwartet sind und beim Durchlesen des Codes so nicht zu passen scheinen. Auch Methoden, die vom Namen her z. B. eine nur lesende Aktion vermuten lassen und dann wild in den Daten schreiben oder löschen. Das fühlt sich nicht richtig an.
Solche Punkte zu identifizieren ist meist schwer, da sich solche Stellen oft über mehrere Iterationen oder Codeänderungen einschleichen. Um diese zu finden, helfen nur gemeinsame Reviews mit Kollegen. Andere Überraschungen wie komisch benannte Verzeichnisse lassen sich durch einheitliche Projektstrukturen verhindern.

Damit dies auch im Team gelingt, ist es sinnvoll einen Code- oder Projektguide zu erstellen. Dieser muss jedoch nicht zwingend allumfassend sein und alles bis ins Kleinste regeln.
Bevor man nun eine der bekannten Codeguidelines auf sein Projekt anwendet, sollte man sich im Team intensiv damit beschäftigt haben. Bei sich widersprechenden Regelungen sollte im Vorfeld eine Entscheidung getroffen werden, welche man durchsetzen will.
Es sollte zudem nur das geregelt werden, was man auch automatisiert prüfen kann. Erfahrungsgemäß wird es sonst sowieso nicht überprüft.

Fazit: Die Codequalität beginnt aber immer bei jedem Einzelnen von uns. Man sollte Code so schreiben, dass man sich in Zukunft auch selbst noch darin wohlfühlen kann.
Andernfalls hilft vermutlich nur der regelmäßige Wechsel des Wohnsitzes.