>>Any fool can write code that a Computer can understand. Good programmers write code that humans can understand.«
Martin Fowler, >>Refactoring<<
Eine Programmiersprache ist in erster Linie eine künstliche Sprache zur Kommunikation von Menschen mit Maschinen. lm Unterschied zu natürlichen Sprachen, die der Kommunikation zwischen Menschen dienen, sind Programmiersprachen vollkommen eindeutig definiert: Es gibt keinerlei lnterpretationsspielraum, was ein bestimmtes Sprachkonstrukt bedeutet. Diese Eigenschaft macht die Sprache maschinenlesbar.
Dass Programmiersprachen keine Mehrdeutigkeiten zulassen, bedeutet jedoch nicht, dass Missverständnisse ausgeschlossen sind, denn sie haben noch eine zweite wichtige Funktion: Sie sind ein Kommunikationsmittel zwischen dem ursprünglichen Programmierer, der das Programm geschrieben hat, und einem anderen, der es später liest. Da Menschen etwas weniger logisch denken als Computer, kann es dazu kommen, dass der Programmierer nicht schreibt, was er meint, oder dass ein zweiter Programmierer den Text des ersten Programmierers falsch versteht.
Unangenehm wird es, wenn dieser zweite Programmierer auf Grundlage seines falschen Verständnisses den Code verändert oder falsch aufruft, denn dann geht mit großer Wahrscheinlichkeit etwas kaputt. In vielen Fällen ist der zweite Programmierer mit dem ersten identisch - er ist nur ein paar Wochen oder Monate älter.
Diese Missverständnisse sind es, die Zeit kosten und, falls sie nicht erkannt und ausgemerzt werden, zu Abstürzen oder falschen Ergebnissen führen. Für gute Programmierer hat das Vermeiden von Missverständnissen daher allerhöchste Priorität.
Jede unserer Äußerungen, ob sie im Gespräch mit einem Menschen stattfindet, beim Schreiben von Büchern oder beim Programmieren, enthält nur einen Teil der zum Verständnis nötigen Informationen. Der andere Teil bleibt unausgesprochen im Kopf zurück. Was wir im ersten Versuch von uns geben, ist deshalb meistens miss- und oft ganz unverständlich. Wir merken das nur selten, weil sich kaum jemand die Mühe macht, nachzufragen. Der Gesprächspartner hat nicht so ganz zugehört, weil er darüber nachdenkt, was er selbst Wirres sagen will, und Leser haben nicht immer die Möglichkeit, einen Autor so lange zu schütteln, bis der sich verständlich ausdrückt. Nicht zuletzt wegen dieses fehlenden Feedbacks neigen wir fast alle dazu, die Gedankenlesefähigkeiten von Lesern, Zuhörern und Computern zu überschätzen. »Aber das steht da doch!«, protestieren wir auf Nachfrage, und »Hab ich doch gesagt!« In Wirklichkeit haben wir es uns bestenfalls gedacht.
Mit dem Schreiben verständlichen Codes, dem Nachdenken über Namensgebung und dem Kommentieren verhält es ein bisschen wie mit Safer Sex: Jeder erkennt den Nutzen und ist dafür, und doch wird es zu selten praktiziert - insbesondere, wenn es wirklich drauf ankommt. Das Haupthindernis ist dabei psychologischer Natur: Im Moment des Schreibens hat man Verständnishilfen nicht nötig. Man weiß, was man tut, und alle nötigen Informationen kursieren noch frisch im Kurzzeitgedächtnis. Außerdem will man mit dem Programm weiterkommen und sich nicht durch das Schreiben von Kommentaren ablenken lassen.
Der Autor müsste sich also in fremde Leser seines Codes hineinversetzen und deren Bedürfnisse nachvollziehen, was zusätzliche Arbeit verursacht und deshalb gern unterlassen wird. Manchmal missachtet er diese Bedürfnisse sogar ganz bewusst, etwa wie er die andren Leser als Konkurrenten um seinen Arbeitsplatz wahrnimmt.
Ob man sich um lesbaren Code bemüht, hängt also auch wesentlich davon ab, welches Verhältnis man zu seinen imaginären Codelesern hat. Dieses Verhältnis lässt sich freundlicher gestalten mithilfe der von buddhistischen Weisen sowie den Fantastischen Vier beschriebenen Einsicht, >>Du bist wie die andern und die andern sind wie du.« Die Leser, die jede Hilfe beim Verständnis des Codes gebrauchen können, sind wir selbst - heute beim Versuch, den Code anderer zu verstehen, und morgen beim Betrachten des eigenen Codes. Die Erkenntnis, dass der eigene Code einem sehr schnell sehr fremd wird, ist unter Programmierern so weit verbreitet, dass sie schon vor Jahrzehnten Gesetzesform angenommen hat. >>Eagleson's Law« lautet: >>Any code of your own that you haven't looked at for six or more months might as well have been written by someone eise.« Eine Ergänzung: Eagleson war Optimist, in Wirklichkeit sind es eher drei Wochen.
Widerstehen Sie daher der Einflüsterung >>Das merkst du dir doch auch so!<< des Codeteufels. Es schadet nicht, sich beim Programmieren vorzustellen, man sei der Protagonist aus »Memento«, der alles, was er nicht sofort schriftlich festhält, wenige Minuten später wieder vergessen hat. Das hat auch mit Respekt vor der eigenen Arbeitszeit zu tun, denn dass man einmal Zeit auf das mühsame Verstehen eines Problems aufgewendet hat, heißt nicht, dass man es ab jetzt für immer verstehen wird. Auch Verständnis hat ein Verfallsdatum, und man kann heute schon die Zeit von morgen einsparen, indem man sich selbst das Verstandene aufschreibt und erklärt. Dass dadurch auch andere Menschen den Code leichter erfassen können, ist eine praktische Nebenwirkung.
KAPITEL 4