Was zeichnet lesbaren Code aus?

Inhaltsverzeichnis

Während man Code schreibt, achtet man als Entwickler primär darauf, dass der Code funktioniert. Wie gut lesbar der Code ist, ist dabei häufig zweitrangig. Doch langfristig gesehen ist die Lesbarkeit gerade das, was über die Wartbarkeit von Code entscheidet. Was also zeichnet gute Lesbarkeit aus?

Programmieren ist eine kognitiv herausfordernde Tätigkeit. Sie erfordert ein hohes Maß an Abstraktion und systematischem Denken. Hinzu kommt, dass die zu lösenden Probleme schwierig sind, in fachlicher und häufig auch in technischer Hinsicht. Der Effekt davon ist, dass man beim Schreiben von Code auf das Verstehen des Problems und das Finden der Lösung fokussiert ist.

Mehr Infos

Götz & Golo

"Götz & Golo" ist eine gemeinsame Serie von Götz Martinek und Golo Roden. Der eine ist Geschäftsführer der sodge IT GmbH, der andere CTO der the native web GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Götz findet sich im Blog von Sodge IT. Die Fragestellung zu diesem Beitrag lautete: "Was zeichnet lesbaren Code aus?"

• Februar 2020: Günstigere Software durch weniger Tests
• Januar 2020: Module für JavaScript und Node.js auswählen
  
• Dezember 2019: Wie viele Programmiersprachen sind zu viel?
• November 2019: Tools für Web- und Cloud-Entwicklung
• Oktober 2019: Virtuell vereint: Wann Teams remote und/oder vor Ort gut zusammenarbeiten
  
• September 2019: Plädoyer für eine offene und tolerante Kommunikation in der IT-Unternehmenskultur

Worüber man beim konzentrierten Schreiben von Code häufig weniger nachdenkt, ist dessen Lesbarkeit. Die Gedanken kreisen dermaßen um das zugrundeliegende Problem und dessen Lösung, dass die äußere Form der Lösung zur Nebensache wird.

Der Grund dafür ist naheliegend: Da man sich beim Schreiben gedanklich so intensiv mit dem eigentlichen Problem auseinandersetzt, ist eine gute Lesbarkeit nicht erforderlich, um das Problem oder dessen Lösung nachvollziehen zu können.

Optimieren für das zukünftige Ich

Allerdings gilt das natürlich nicht für andere Entwickler. Ihnen fehlt die regelmäßige und intensive Beschäftigung mit dem Thema – und das gleiche gilt auch für das eigene, zukünftige Ich.

Nun könnte man sagen, dass es doch ein Leichtes sei, diesen Missstand zu beheben: Man müsse lediglich, nachdem man den Code geschrieben habe, ihn noch einmal im Hinblick auf Les- und Nachvollziehbarkeit überarbeiten. Doch das geschieht in der überwiegenden Zahl der Fälle nicht. Warum nicht?

Die Antwort auf diese Frage ist ganz einfach: Da es zeitlich in vielen Fällen schon aufwendig war, das Problem an sich überhaupt zu lösen, fehlt es nun an der Zeit, das Ergebnis auch noch "hübsch" zu machen. Da das nicht direkt auf die Anzahl der entwickelten Features einzahlt, wird das Verbessern der Lesbarkeit als vermeintlich optional hinten angestellt.

Unverständlicher Code ist schwer zu pflegen

Langfristig gesehen rächt sich dieses Vorgehen aber. Denn wenn man Code nicht mehr lesen und verstehen und ihn daher auch nicht mehr nachvollziehen kann, wird es extrem schwer, ihn zu pflegen und weiterzuentwickeln.

Nun lässt sich auf zahlreichen Ebenen darüber diskutieren, was lesbaren Code auszeichnet, und wie man die Lesbarkeit verbessern kann. Als einfache Metrik gilt aber, dass Code dann gut lesbar ist, wenn ein anderer ohne große Mühe nachvollziehen kann, was der Code macht, und warum er es macht. Es geht also letztlich um das Optimieren der Nachvollziehbarkeit.

Dabei kann man über die Architektur des Gesamtprojekts genauso sprechen wie über jede einzelne Zeile. Das, worauf man als Entwickler aber direkten Einfluss hat, ist die einzelne Zeile, sowohl des Codes, den man neu schreibt, als auch des Codes, den man vorfindet und gemäß der Pfadfinderregel verbessern kann.

Fünf Regeln

Im Folgenden werden daher fünf Regeln vorgestellt, die zwar keinen Anspruch auf Vollständigkeit erheben, sich aber im Alltag bewährt haben:

• Code sollte einer einheitlichen Formatierung folgen, die entweder über einen Linter oder eine automatische Formatierung erzwungen wird. Je weniger Platz für individuellen Stil bei Einrückung, Leerzeilen, Klammersetzung und ähnlichem bleibt, desto weniger muss man darüber nachdenken, warum Code auf diese und jene Art formatiert ist.
• Variablen- und Funktionsnamen sollten fachlich und nicht technisch gewählt werden und die ursprüngliche Intention widerspiegeln. Das heißt auch, in Bezeichnern auf Wörter wie Service und Manager nach Möglichkeit zu verzichten, da sie wenig Aussagekraft besitzen, und sie durch stärkere Begriffe zu ersetzen.
• Code innerhalb einer Funktion sollte sich ungefähr auf demselben Detailgrad bewegen. Unterscheidet sich der Detailgrad zwischen einzelnen Zeilen sehr stark, ist es ratsam, die spezifischeren Zeilen in eine Funktion auszulagern, und dieser wiederum einen fachlich aussagekräftigen Namen zu geben.
• Technisch spricht prinzipiell nichts dagegen, auch fortgeschrittene Sprachkonstrukte zu verwenden – allerdings darf das niemals zum Selbstzweck werden. Im Zweifelsfall sollte man das etwas einfachere Konstrukt dem anspruchsvolleren vorziehen, auch wenn es länger zu schreiben ist. Kürze alleine führt nicht zu besserer Lesbarkeit – häufig ist genau das Gegenteil der Fall.
• Kommentare sollten nicht das Was dokumentieren, sondern das Warum: Was der Code macht, sollte der Code selbst auf lesbare und nachvollziehbare Art beschreiben, warum der Code aber auf eine bestimmte Art geschrieben wurde und welche Abwägungen getroffen wurden, das sollte in einem Kommentar stehen.

Fazit

Wie gesagt erheben die vorgestellten Regeln keinen Anspruch auf Vollständigkeit, und wie immer gibt es natürlich auch zu diesen Regeln legitime Ausnahmen. Dennoch bieten sie einen guten ersten Anhaltspunkt, und sind teilweise auch gar nicht so einfach zu erfüllen, wie es auf den ersten Blick scheint. Alleine die Forderung, fachlich sprechende Bezeichner zu wählen, ist gelegentlich gar nicht so einfach.

Wer diesen Regeln aber folgt, kommt dem Ziel, les- und nachvollziehbaren Code zu schreiben, auf jeden Fall näher, als wer sie gänzlich ignoriert.

tl;dr: Lesbarkeit ist gleichbedeutend mit Nachvollziehbarkeit. Beim Schreiben von Code wird darauf wenig Wert gelegt, weil man gedanklich mit der Lösung eines anspruchsvollen Problems beschäftigt ist. Trotzdem gibt es Regeln, die man als Basis beachten sollte, um zumindest die gröbsten Schnitzer zu vermeiden. ()