Zum Inhalt springen

Was bedeutet Clean Code im Projektalltag?

Der Begriff wird gern als Qualitätsversprechen verkauft und ebenso gern als Rechtfertigung für Umbauten benutzt, die niemand bestellt hat. Dieser Text sagt, was praktisch dahintersteckt — und was es Ihnen bringt.

  • Für wenAuftraggeber, Projektverantwortliche
  • NiveauHintergrund
  • Lesezeitetwa 6 Minuten
  • Stand16. Oktober 2026

Das lernen Sie

  • Warum Lesbarkeit eine wirtschaftliche Größe ist
  • Fünf Eigenschaften, an denen man es konkret festmachen kann
  • Wo der Begriff überreizt wird
  • Welche Frage Sie im Projekt stellen können

Warum Lesbarkeit Geld ist

Code wird einmal geschrieben und danach viele Male gelesen: bei jeder Änderung, bei jeder Fehlersuche, bei jedem Wechsel des Bearbeiters. Was beim Schreiben eine Viertelstunde spart, kann beim zehnten Lesen eine Stunde kosten.

Deshalb ist die Frage nicht „ist der Code schön", sondern: Wie lange braucht jemand, der ihn nicht geschrieben hat, um eine Änderung sicher vorzunehmen? Diese Zeit zahlen Sie bei jeder Erweiterung mit.

Fünf Eigenschaften, die man prüfen kann

  • Namen sagen, was gemeint ist. `$liste` sagt nichts, `$offeneAuftraege` sagt alles — ohne Kommentar.
  • Eine Funktion tut eine Sache. Wenn ihr Name ein „und" braucht, sind es zwei.
  • Die Fachsprache des Betriebs steht im Code. Heißt der Vorgang bei Ihnen „Abruf", sollte er nicht „Order" heißen.
  • Der Normalfall steht vorn, die Sonderfälle werden früh abgefangen. Verschachtelte Bedingungen über fünf Ebenen sind ein Warnzeichen.
  • Es gibt Tests für die Fälle, die weh tun. Nicht für alles — für die, deren Fehlverhalten jemanden trifft.
PHPgeprüft mit PHP 8.3
// Schwer zu lesen: alles verschachtelt, nichts benannt
if ($a !== null) {
    if ($a->getStatus() === 2) {
        if (count($a->getItems()) > 0) {
            // ... die eigentliche Arbeit, vier Ebenen tief
        }
    }
}

// Lesbar: Sonderfaelle zuerst, Fachsprache im Namen
if ($auftrag === null) {
    return;
}
if (!$auftrag->istFreigegeben()) {
    return;
}
if ($auftrag->positionen() === []) {
    return;
}

// ... die eigentliche Arbeit, ohne Einrueckung
Beide Fassungen tun dasselbe. Die zweite lässt sich erweitern, ohne sie vorher zu verstehen.

Ein Beispiel aus der Praxis

Wenn die Fachsprache fehlt

In einer übernommenen Anwendung hieß eine zentrale Methode `process()`. Sie prüfte den Bestand, legte einen Vorgang an, verschickte zwei Mails und schrieb ein Protokoll. Jede Änderung an einem dieser vier Teile bedeutete, die ganze Methode zu verstehen — und zu hoffen, die anderen drei nicht zu beschädigen.

Die Aufteilung in vier benannte Schritte hat keinen Buchstaben Fachlogik geändert. Sie hat die nächste Änderung von einem Risiko zu einer Routine gemacht. Das ist der ganze Punkt.

Wo der Begriff überreizt wird

„Das ist kein Clean Code" ist kein Argument, solange niemand sagt, welche konkrete Änderung dadurch teurer wird. Ein Umbau, der nur die Form ändert, hat einen Preis und keinen messbaren Nutzen — und er bringt das Risiko mit, funktionierendes Verhalten zu verändern.

Wir halten es deshalb so: Umgebaut wird, was gerade sowieso angefasst wird, und das in dem Umfang, den die anstehende Änderung braucht. Ein Umbau als eigenes Vorhaben braucht eine Begründung, die einen Namen hat — etwa eine Stelle, an der Fehler wiederholt entstanden sind.

Häufige Missverständnisse

Beim ersten Schreiben manchmal. Bei der dritten Änderung ist es umgekehrt, und die dritte Änderung kommt immer.

Ein Kommentar, der erklärt, was eine Zeile tut, ist meist ein Hinweis auf einen schlechten Namen. Wertvoll sind Kommentare, die erklären, warum etwas so ist — die Begründung steht nicht im Code.

Es betrifft Ihren Preis für die nächste Änderung. Das ist der direkteste Weg, auf dem Codequalität bei Ihnen ankommt.

Über den Autor

Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.