Code-Verständlichkeit hängt davon ab, wie gut geschriebener Code zum menschlichen Arbeitsgedächtnis passt. Das Arbeitsgedächtnis verarbeitet gleichzeitig nur etwa vier sogenannte Chunks, also Informationsklumpen aus dem Langzeitgedächtnis. Gutes Naming, kurze Methodensignaturen und das Vermeiden von Seiteneffekten reduzieren die Anzahl aktiver Chunks und machen Code für alle Teammitglieder lesbar.
Das Wichtigste in Kürze
- Das Arbeitsgedächtnis kann gleichzeitig nur etwa vier sogenannte Chunks verarbeiten, weshalb ein Methodenaufruf mit Objekt, Methode und zwei Argumenten bereits diese Grenze ausschöpft.
- Chunks im Langzeitgedächtnis sind keine einheitlich kleinen Einheiten: Ein einziger Chunk kann viele Unterinformationen gleichzeitig aktivieren, was Abstraktion so wirkungsvoll macht.
- Gutes Naming bedeutet, dass der gewählte Begriff bei möglichst vielen Lesern den gleichen Chunk aktiviert, also ähnliche Assoziationen auslöst wie beim Autor.
- Zustandsübergänge in Code überfordern das Gehirn, weil es zwar Zustandsänderungen wahrnehmen, sie aber nur schwer intern nachsimulieren kann, was funktionale Programmierung ohne Seiteneffekte kognitiv begünstigt.
- Pair Programming synchronisiert die Chunk-Bildung zweier Entwickler: Was der Navigator nicht versteht, ist ein verlässliches Signal, dass der Code auch für andere schwer lesbar sein wird.
Verständlicher Code ist eine Frage des Gehirns, nicht des Geschmacks
Ob Code lesbar ist, entscheidet sich daran, wie gut ihn ein menschliches Gehirn verarbeiten kann. Genau hier setzen Stefan Mandel und Peter Guntermann an. Beide arbeiten als Softwareentwickler und beschäftigen sich intensiv mit Clean Code. Statt die Regeln aus Robert C. Martins Buch einfach hinzunehmen, haben sie nach der Begründung dahinter gesucht: Warum funktionieren diese Empfehlungen überhaupt?
Das Problem, das den Anstoß gab, kennt jeder im Team. Ein Junior schreibt eine Methode mit vier Argumenten, ein erfahrener Kollege sagt, sowas mache man nicht, und auf die Frage nach dem Warum kommt bestenfalls ein Verweis auf ein Buch. Das hilft nur begrenzt. Niemand kann tausend Bücher auswendig kennen, und manche widersprechen sich sogar.
Die bessere Antwort liegt eine Ebene tiefer. Wer versteht, wie das Gehirn Code aufnimmt, kann sich gute Praktiken selbst erschließen und sie anderen erklären. Statt “das macht man nicht” lässt sich dann sagen: dein Gehirn wird überlastet, also reduziere die Information.
Wie das Arbeitsgedächtnis Code verarbeitet
Das Gehirn verarbeitet beim Code-Lesen nur eine begrenzte Menge Information gleichzeitig. Stefan und Peter unterscheiden zwischen Arbeitsgedächtnis und Langzeitgedächtnis. Das Arbeitsgedächtnis ist der Teil, der aktiv rechnet, wenn du eine Code-Zeile durchgehst, und genau dieser Teil ist eng limitiert.
Die zentrale Einheit dabei heißt Chunk. Ein Chunk ist ein Informationsklumpen, der im Langzeitgedächtnis abgelegt ist. Jedes Wort im Code, jeder Variablen-, Methoden- oder Klassenname wird auf einen solchen Chunk abgebildet. Wer eine Programmiersprache gelernt hat, trägt Chunks für ihre Grammatik mit sich und kann den Code intern nachsimulieren.
Das Arbeitsgedächtnis kann gleichzeitig nur etwa vier Chunks verarbeiten. Die Psychologie spricht von vier plus minus eins. Ab dem fünften Element wird es richtig schwierig. Beim vierten ist die Grenze erreicht, alles darunter läuft locker.
Eine typische Code-Zeile bleibt deshalb gut beherrschbar. Eine Zuweisung besteht aus einem Objekt, einer Methode und einem Argument. Das sind drei beteiligte Chunks, das Ergebnis kommt erst am Ende heraus und belegt vorher keinen Platz. Drei Chunks verarbeitet das Arbeitsgedächtnis ohne Mühe.
Erfahrung erweitert nicht die Kapazität, sondern die Chunks
Mehr Erfahrung macht das Arbeitsgedächtnis nicht größer, sie macht die einzelnen Chunks mächtiger. Die Vier-Chunk-Grenze gilt für alle. Den Unterschied macht, wie viel hinter einem einzelnen Chunk steckt.
Die Größe eines Chunks ist nicht einheitlich. In der Informatik kommt das dem Begriff der Abstraktion am nächsten. Wer Design Patterns kennt und das Wort “Observer” hört, hat sofort eine Vorstellung vom dahinterliegenden Konzept, ohne jedes Detail einzeln durchzugehen.
Das Gehirn arbeitet dabei anders als ein Computer. Es rechnet nicht nur symbolisch auf der Abstraktion. Die Detail-Chunks unter einer Abstraktion feuern gleichzeitig mit. Vier Informationen gleichzeitig, aber in jeder können viele Unterinformationen stecken. So lässt sich in einem Schritt deutlich mehr verarbeiten.
Code ist Kommunikation, kein Monolog
Code ist eine Form von Kommunikation, und der Empfänger braucht dieselben Chunks wie der Sender. Du hast eine Anforderung, gießt sie in ein Feature und schreibst Code. Jemand anderes liest ihn später, und dieser Jemand bist oft du selbst, nur Wochen später.
Ein Begriff wie “Observer” hilft nur, wenn dein Gegenüber ihn kennt. Wer einen Chunk benutzt, den der andere nicht hat, kommuniziert ins Leere. Verständlicher Code entsteht, wenn die Chunks beider Seiten ähnlich vernetzt und mit denselben Dingen assoziiert sind.
Daraus folgt eine praktische Konsequenz für die Teamarbeit. Du schreibst nicht für deine eigene, vielleicht abstruse Idee, sondern für deine Teammitglieder. Informatik enthält deshalb sehr viel Kommunikationsarbeit, lange bevor eine Zeile compiliert.
Warum sprechende Namen oft danebengehen
Gutes Naming bedeutet, dass möglichst viele Leute unter einem Begriff dasselbe verstehen. Naming gilt als eines der schwersten Probleme der Informatik, und das aus gutem Grund. Ein Name muss den richtigen Chunk im Kopf des Lesers treffen.
Sprechende Namen werden allerdings häufig falsch verstanden. Manche glauben, sie dürften keine kurzen Bezeichner mehr verwenden. Das stimmt nicht. Ein x für die X-Koordinate ist eine Konvention, niemand muss xKoordinate schreiben. Du darfst dem Leser eine gewisse Cleverness unterstellen.
Der umgekehrte Fehler ist genauso schädlich. Wer ein Konzept nicht in einem Wort fasst, packt manchmal einen ganzen Satz in den Variablennamen. Jeder Wortbestandteil wird als Chunk verarbeitet. Ist der Name zu lang, hast du am Ende schon vergessen, was am Anfang stand. Kürze und Prägnanz schlagen ausführliche Beschreibung.
Lange Kommentare lösen das Problem nicht. Ein elendlanger Kommentar vor einer Variable strengt das Gehirn an, weil du ihn sorgfältig vorab lesen musst. Ein guter Kommentar ist besser als nichts. Lässt sich die Bedeutung aber schon im Namen anlegen, ist das die bessere Wahl.
Wie viele Argumente eine Methode verträgt
Die verbreitete Empfehlung von etwa zwei Argumenten pro Methode ergibt sich direkt aus der Vier-Chunk-Grenze. Bei einem Methodenaufruf verarbeitest du nicht nur die Argumente. Du behältst auch im Kopf, welche Methode aufgerufen wird und auf welchem Objekt.
Damit sind bei zwei Argumenten bereits vier Chunks im Spiel: das Objekt, die Methode und die zwei Argumente. Ein drittes Argument macht fünf, und dann hängst du Leser ab, die mit fünf nicht mehr zurechtkommen.
Es gibt einen Ausweg. Eine Abstraktion, die zwei Parameter sinnvoll zusammenfasst, senkt die Zahl der Chunks wieder. Der Preis dafür ist Allgemeingültigkeit. Wer eine Methode bewusst variabel halten will, kann nicht für jeden Aufruf eine neue Abstraktion erfinden und muss die Argumente als gleichberechtigte Chunks nebeneinander stehen lassen.
Zustand und Seiteneffekte überfordern das Gehirn
Seiteneffekte sind schwer verständlich, weil das Gehirn Zustandsübergänge schlecht intern nachbildet. Zählt eine Methode im Hintergrund einen Counter hoch, musst du diesen Zustand zusätzlich im Kopf behalten, während du den eigentlichen Ablauf verfolgst.
Funktionale Programmierer raten aus genau diesem Grund von Seiteneffekten ab. Ein Chunk lässt sich nicht beliebig schnell umschreiben. Weist du eine Variable neu zu, steckt plötzlich ein anderer Wert dahinter, und die alte Assoziation passt nicht mehr.
Das Gehirn ist sehr gut dafür ausgelegt, Zustandsänderungen wahrzunehmen, aber nicht, sie intern zu reproduzieren. — Stefan Mandel
Dieselbe Logik erklärt, warum hohe zyklomatische Komplexität anstrengt. Jede Bedingung, die dich an eine Codestelle geführt hat, musst du im Kopf mittragen. Irgendwann ist das Arbeitsgedächtnis voll mit Verzweigungen, du verdrängst Information, und die Ergebnisse werden ungenau.
Metriken filtern das Unwichtige, ersetzen aber kein Urteil
Softwarequalitäts-Metriken sind ein nützlicher, aber unzureichender Indikator für Verständlichkeit. Sie sind weder hinreichend noch notwendig. Eine Metrik lässt sich gelegentlich auch schlicht austricksen.
Die gängigen Metriken sind grundsätzlich kompatibel mit dem Chunk-Modell. Hohe zyklomatische Komplexität deutet mit einer gewissen Wahrscheinlichkeit auf unlesbaren Code hin. Es gibt aber komplexen Code, der trotzdem gut lesbar ist, und es gibt unlesbaren Code, dessen Problem an ganz anderer Stelle liegt.
Naming etwa entzieht sich jeder Metrik. Ob hinter einem Namen das Richtige vermutet wird, kann keine Technik bewerten. Metriken nehmen dir die Beinarbeit ab und filtern das offensichtlich Unwichtige heraus. Beim Naming aber lässt sich jede Prüfung aushebeln.
So synchronisierst du Chunks im Team
Gemeinsame Chunks entstehen durch gemeinsame Erfahrung, und die wichtigste Maßnahme dafür ist schlicht miteinander reden. Chunks werden im Gehirn angelegt, wenn man Ereignisse wahrnimmt. Wer dieselben Ereignisse teilt, entwickelt ähnliche Vorstellungen.
Mehrere Praktiken zielen genau darauf:
- Code-Formatierung automatisieren. Ein Formatter sorgt dafür, dass die Präsentation den Leser nicht zusätzlich belastet.
- Variablen kurz leben lassen. Eine Variable, die unnötig lange existiert, musst du die ganze Zeit im Kopf zwischenspeichern. Das überfordert dich und andere.
- Abkürzungen vermeiden. Drei-Buchstaben-Kürzel sind ein Klassiker. Wenn sie nicht zum Verständnis beitragen, lass sie weg.
- Pair Programming nutzen. Hat ein Driver eine schräge Vorstellung davon, was ein guter Chunk ist, fällt es dem Navigator sofort auf. Beide legen denselben Chunk gleichzeitig an, und diese synchrone Festigung sorgt für ein geteiltes Verständnis.
Ein Muster verrät die Schwachstelle. Wer eigenen Code nach zwei Wochen nicht mehr lesen kann, hat einen Chunk nur beim Schreiben einmal erzeugt und nie wieder genutzt. Stefan nennt das Ad-hoc-Chunking: in dem Moment plausibel, aber nicht gefestigt, weil wertlos. Wenn dem Navigator etwas schwer in den Kopf geht, geht es anderen genauso. Dann lohnt es sich, im Code nachzuschärfen.
Was KI-Assistenten zur Lesbarkeit beitragen
KI-Assistenten wie Copilot helfen beim Verständnis, neigen aber zur Überproduktion. Wer spricht, kann auch labern, und ein Assistent schüttet dich schnell mit Vorschlägen zu. Auf der anderen Seite kannst du nachfragen, wenn du etwas nicht verstehst, und bekommst eine Erklärung.
Ein Selbstversuch zeigt die aktuellen Grenzen. Auf die Bitte, ein Beispiel lesbarer zu machen, verlängerte das Tool zuverlässig die Namen, blähte die Methodennamen auf mehrere Wörter auf und setzte stets eine vierzeilige Dokumentation davor.
Der eigentliche Witz steckte im Detail. Eine Methode namens “difference of squares” sollte x² - y² berechnen, ausgerechnet wurde aber (x - y) * (x + y). Mathematisch äquivalent, aber als Begründung für den Namen unlesbar. Die direkte Schreibweise wäre weniger performant, aber besser verständlich gewesen.
Solche Erklärungen liefern KI-Tools mechanisch, nicht durchdacht. Für eine andere Aufgabe taugen sie dafür sofort: sich eine reguläre Ausdrücke erklären zu lassen, dort wo man als Mensch gern aussteigt.
