Wahrscheinlich kennen alle Softwareentwickler ein Programm oder Projekt, das sie am liebsten noch einmal neu beginnen würden. Die bestehende Lösung ist nicht mehr zu durchschauen, und viele getroffene Entscheidungen sind nicht mehr nachvollziehbar. Wie sich die Lesbarkeit von Code verbessern lässt, zeigt dieser Artikel an ein paar einfachen Beispielen.

„Jeder Depp kann Code schreiben, den ein Computer verstehen kann. Gute Programmierer schreiben Code, den Menschen verstehen können“, so Martin Fowler [1]. Aber was ist eigentlich lesbarer Code? Laut Wikipedia bezeichnet Lesbarkeit „die Leichtigkeit, mit der ein menschlicher Leser den Zweck, Kontrollfluss und Arbeitsablauf von Quelltext nachvollziehen kann“ [2]. Es geht also darum, möglichst leicht zu verstehen, was der Code tut. Aber warum ist es wichtig, Code lesen zu können? Wenn der Code funktioniert, dann muss ich ihn doch nicht mehr ändern, oder?

Ein Grund für die Entwicklung lesbarer Programme ist simpel: Code wird sehr häufig gelesen. Wenn man nicht gerade ein Modul schreibt, das an einem Tag fertiggestellt werden kann, muss man sich am nächsten Tag wieder einarbeiten. Häufig kommt es vor, dass nach der ersten Implementierung noch mehrfach Anpassungen und Weiterentwicklungen notwendig werden, sodass man bestehenden Code neu lesen und verstehen muss. Spätestens beim Bugfixing muss man sich erneut in den Code einarbeiten, obwohl sich der Fehler letztendlich sogar in einem anderen Modul befinden kann. Je nach Projektsituation ist es außerdem wahrscheinlich, dass sich ein anderer Entwickler in den Code einarbeitet, der sehr stark von gut geschriebenem Code profitieren kann. Es zeigt sich nämlich, dass Quelltext deutlich häufiger gelesen als geschrieben wird. Deshalb ist es wichtig, dass Code nicht nur funktioniert, sondern auch lesbar ist. Auf diese Weise kann man sich schnell einarbeiten und Anpassungen vornehmen.

Benennung von Variablen

„In der Informatik gibt es nur zwei schwere Probleme: Caches invalidieren und Namensgebung.“ [3] Dieses Zitat von Phil Karlton zeigt, dass das Finden von guten Namen ganz schön schwer sein kann, es aber trotzdem wert ist, den Aufwand zu betreiben. Obwohl die Namen keinen direkten Einfluss darauf haben, ob Code richtig funktioniert, sind Namen für die Lesbarkeit und somit die Verständlichkeit von Code sehr wichtig. Namen werden bei jeder Verwendung einer Variablen wiederholt. Wenn eine Variable anhand ihres Namens verstanden werden kann, muss der Leser weniger Informationen suchen und behalten und kann somit schneller arbeiten. Folgendes Beispiel taucht häufig in Projekten auf:

// Die Menge der gezahlten Summe
int sum = 0;

In diesem Fall wird eine Variable initialisiert und in einem Kommentar kurz beschrieben, wofür die Variable eigentlich gedacht ist. Das Problem ist, dass bei einer späteren Verwendung dieser Kommentar nicht mehr sichtbar ist. Man muss erst zur Initialisierung springen, um herauszufinden, welche Summe sich dahinter verbirgt. paidSumInCent ist als Name deutlich aussagekräftiger, sodass man direkt weiß, was sich hinter der Variablen verbirgt. Als Zusatzinformation ist nun sogar enthalten, dass die Summe in Cent angegeben wird, und nicht, wie normalerweise erwartet, in Euro. Der Datentyp int ist schon ein kleiner Hinweis darauf, dass die Summe möglicherweise nicht in Euro gespeichert ist. Um das herauszufinden, muss man sich den Code allerdings doch sehr genau ansehen.

Ein weiterer Vorteil des neuen Namens: Der Kommentar wird nicht mehr gebraucht, da die Informationen aus dem Kommentar bereits im Variablennamen enthalten sind. Das Ziel bei der Benennung von Variablen ist es, einen selbsterklärenden Namen zu finden, der die wichtigsten Informationen enthält. Man sollte vermeiden, dass der Leser ständig zwischen verschiedenen Begriffen wechseln muss.

Eine Ausnahme stellen dabei Laufvariablen in Schleifen dar, die häufig mit „i“ oder „j“ benannt sind. Da der Bereich, in dem die Variablen benutzt werden, sehr klein ist und zumeist nicht mehr als drei Zeilen umfasst, ist ein kurzer Variablenname in Ordnung...