Sauberer Code: Prinzipien, die jedes Projekt besser machen

„Sauberer Code“ klingt nach Ästhetik – nach Geschmackssache. Ist er aber nicht. Sauberer Code ist die Antwort auf die einzige Konstante in Softwareprojekten: Er wird gelesen, geändert und erweitert – und zwar öfter, als er geschrieben wird. Die Prinzipien in diesem Artikel sind keine Moden, sondern Werkzeuge gegen die schleichende Unverständlichkeit, die jedes Projekt ohne Gegenmittel irgendwann erfasst.

1. Namen sind Dokumentation

Der billigste Kommentar ist ein guter Name. Eine Variable, Funktion oder Klasse, die sagt, was sie tut, braucht keine Erklärung daneben – und veraltet auch nicht, weil sie immer bei der Wahrheit bleibt.

php

// ✗ Was wird hier berechnet? Warum 86400?
$d = ($t2 - $t1) / 86400;

// ✓ Der Code erklärt sich selbst
$tageSeitRegistrierung = ($letzteAktivitaet - $registrierung) / SEKUNDEN_PRO_TAG;

Die Regel ist einfach: Lieber einen längeren, präzisen Namen als einen kurzen, den man zweimal lesen muss. Abkürzungen sparen Sekunden beim Tippen und kosten Minuten beim Lesen – jeden Tag wieder.

2. Funktionen tun eine Sache

Die bekannteste Regel sauberen Codes ist auch die am häufigsten missverstandene. „Eine Sache“ heißt nicht „eine Zeile“ – es heißt: keine zwei Ebenen der Abstraktion in einer Funktion. Eine Funktion, die Daten lädt, validiert, formatiert und speichert, tut vier Dinge – und jede Änderung birgt das Risiko, die anderen drei zu beschädigen.

php

// ✗ Vier Verantwortungen in einer Funktion
function verarbeiteBestellung(array $daten): void
{
    $bestellung = mappeEingabe($daten);          // 1. Mapping
    if (!$this->pruefeLager($bestellung)) {     // 2. Validierung
        throw new LagerFehler();
    }
    $this->db->speichere($bestellung);          // 3. Persistenz
    $this->mail->sende($bestellung);            // 4. Benachrichtigung
}

// ✓ Jede Verantwortung hat eine Funktion
function verarbeiteBestellung(array $daten): void
{
    $bestellung = $this->erstelleBestellung($daten);
    $this->stelleSicher($bestellung);
    $this->persistiere($bestellung);
    $this->benachrichtigeKunden($bestellung);
}

Der zweite Code ist nicht kürzer – aber jede Funktion ist einzeln testbar, einzeln veränderbar und auf einen Blick verständlich. Das ist der eigentliche Gewinn.

3. Das Gesetz von Demeter: Sprich nur mit Freunden

Ein Objekt sollte nur mit seinen direkten Nachbarn sprechen, nicht mit Nachbarn von Nachbarn. Kettenaufrufe wie $kunde->getAdresse()->getLand()->getSteuersatz() koppeln deinen Code an die komplette Innenstruktur dreier Klassen. Ändert sich irgendwo ein Detail, bricht deine Zeile.

php

// ✗ Kennt den halben Objektgraphen
$steuersatz = $rechnung->getKunde()->getAdresse()->getLand()->getSteuersatz();

// ✓ Kunde beantwortet die Frage selbst
$steuersatz = $rechnung->steuersatzFuerKunden();

4. Kommentare erklären das Warum, nicht das Was

Ein Kommentar, der beschreibt, was der Code tut, ist ein Hinweis auf unklaren Code – und wird mit der nächsten Änderung zur Lüge. Gute Kommentare existieren trotzdem: Sie erklären Entscheidungen, die der Code nicht ausdrücken kann.

php

// ✗ Wiederholt den Code
// Inkrementiere i um 1
$i++;

// ✓ Erklärt eine Entscheidung, die man sonst nicht versteht
// Timeout bewusst hoch: Der Drittserver braucht im
// Tagesgeschäft bis zu 40 s (Ticket #4821).
$timeout = 60;

5. Konsistenz schlägt Brillanz

Ein Projekt, das überall dieselben Muster nutzt, ist leichter zu lesen als eines mit vielen cleveren Einzellösungen. Die dritte Variante, ein Problem zu lösen, ist keine Bereicherung – sie zwingt jede Lesende zum Umdenken. Einheitliche Namen, einheitliche Fehlerbehandlung, einheitliche Struktur: Das ist keine Langeweile, sondern Respekt gegenüber allen, die nach dir den Code lesen.

Fazit

Sauberer Code ist kein Selbstzweck, sondern Ökonomie: Die meiste Zeit im Leben einer Software wird mit Lesen und Ändern verbracht, nicht mit Schreiben. Namen, die sagen was sie meinen. Funktionen, die eine Sache tun. Weniger Kopplung. Kommentare, die Entscheidungen festhalten. Konsistenz über Brillanz. Keines dieser Prinzipien ist neu – aber ihre konsequente Anwendung ist der Unterschied zwischen einer Codebasis, die man in fünf Jahren noch versteht, und einer, die man neu schreibt.