Lesbarkeit und Wartbarkeit

Was ist Clean Code?

sauberer Quellcode

Clean Code bezeichnet Quellcode, den eine andere Person ohne Rückfragen lesen und gefahrlos ändern kann. Der Begriff steht für eine Reihe von Handwerksregeln zu Benennung, Funktionsgröße, Wiederholung und Struktur, die Robert C. Martin in einem gleichnamigen Buch zusammengetragen hat.

Der Code, den du heute schreibst, wird über Jahre öfter gelesen als geändert, und meistens von jemandem, der nicht dabei war, als er entstanden ist.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Geprägt von: Robert C. Martin
Setzt an bei: Namen, Funktionsgröße, Wiederholung
Prüfbar im: Review, nicht über eine Kennzahl
Verwandt mit: Refactoring und technischer Schuld

Die Regeln, die den meisten Unterschied machen

Namen sollen sagen, was gemeint ist. Eine Variable namens d erklärt nichts, tageSeitRechnung erklärt alles und macht einen Kommentar überflüssig. Dieselbe Regel gilt für Funktionen: Ihr Name beschreibt, was sie tut, und wenn im Namen ein „und“ vorkommt, tut sie zwei Dinge und gehört geteilt.

Funktionen bleiben klein und arbeiten auf einer Abstraktionsebene. Ein Block, der erst eine Datei öffnet, dann Fachlogik rechnet und am Ende Text formatiert, springt zwischen drei Ebenen und zwingt jeden Leser, alle drei gleichzeitig im Kopf zu halten. Nach dem Zerlegen liest sich die äußere Funktion wie eine Inhaltsangabe.

Duplikate sind der teuerste Fehler, weil eine Korrektur an einer Stelle die anderen unverändert lässt. Und die Boy-Scout-Rule fasst zusammen, wie Verbesserung ohne Großprojekt funktioniert: Du hinterlässt jede Datei, die du anfasst, ein wenig aufgeräumter, als du sie vorgefunden hast.

Warum Kommentare oft ein Warnsignal sind

Ein Kommentar, der erklärt, was der Code tut, ist meist der Versuch, unklaren Code zu entschuldigen. Statt zu beschreiben, dass hier die Frist geprüft wird, benennst du die Funktion so. Der Vorteil ist nicht nur Kürze: Kommentare veralten still, weil sie beim Ändern niemand mitzieht, Namen dagegen stehen mitten im Weg.

Wertvoll bleiben Kommentare, die das Warum festhalten. Wenn eine Sonderbehandlung existiert, weil ein Fremdsystem ein bestimmtes Datumsformat liefert, gehört genau das in den Code, denn diese Information steht nirgends sonst.

Wie du es im Team durchsetzt

Als Vorsatz funktioniert Clean Code nicht. Was funktioniert, ist ein automatisch laufender Formatierer, damit über Einrückung nie wieder diskutiert wird, dazu statische Analyse im Durchlauf der Pipeline und ein Review, das auf Verständlichkeit schaut statt auf Geschmack.

Aufräumen ohne Tests ist dagegen ein Risiko. Bevor du eine gewachsene Funktion zerlegst, brauchst du eine Absicherung, die zeigt, dass das Verhalten gleich bleibt. Genau in dieser Reihenfolge, erst Testabdeckung, dann Umbau, wird aus Refactoring eine ruhige Arbeit statt einer Wette.

Und die Regeln sind Werkzeuge, keine Gebote. Eine Funktion in drei Zeilen aufzuteilen, nur um unter einer Zeilengrenze zu bleiben, macht den Code nicht lesbarer, sondern verteilt ihn. Maßstab bleibt immer, ob jemand anderes den Ablauf beim ersten Lesen versteht.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Clean Code und was oft damit gleichgesetzt wird

Clean Code gegen Entwurfsmuster

Entwurfsmuster sind Lösungsschablonen für wiederkehrende Entwurfsprobleme. Clean Code betrifft die Ebene darunter, also Benennung und Struktur im Kleinen, unabhängig davon, welches Muster du wählst.

Clean Code gegen Refactoring

Refactoring ist die Tätigkeit, die Struktur zu ändern, ohne das Verhalten anzutasten. Clean Code beschreibt den Zustand, den du damit anstrebst.

Clean Code gegen Technische Schuld

Technische Schuld ist die bewusst oder unbewusst aufgeschobene Aufräumarbeit samt ihrer Zinsen in Form langsamerer Änderungen. Unsauberer Code ist ihre häufigste Form.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Ohne verbindliche Regeln entscheidet der Lauteste im Review

Diskussionen über Einrückung und Anführungszeichen gehören nicht in ein Review. Ein Formatierer, der beim Speichern läuft, und ein Linter mit einmal abgestimmten Regeln nehmen diese Themen vollständig aus dem Gespräch, und danach reden alle über Fachlichkeit statt über Leerzeichen.

Ein Kommentar, der erklärt, was die nächsten zehn Zeilen tun, beschreibt meistens eine Funktion, die noch keinen Namen hat. Wertvoll bleiben Kommentare, die das Warum festhalten, etwa warum eine Berechnung von der offensichtlichen Formel abweicht, weil eine Abrechnungsregel es so verlangt. Alles andere veraltet still und führt den nächsten Leser in die Irre.

Im gewachsenen System scheitert der große Aufräumauftrag zuverlässig. Was funktioniert, ist die Regel, dass jede Datei, die du ohnehin anfasst, ein Stück besser zurückbleibt, als du sie vorgefunden hast. Das ist überprüfbar, passt in jedes Review und braucht kein eigenes Budget.

Clean Code lernen

Wo im eigenen Code die teuren Stellen liegen und wie du sie ohne Risiko entschärfst, arbeiten die Clean-Code-Trainings für Entwicklerteams an mitgebrachten Beispielen heraus.

Kurse, die Clean Code behandeln

Häufige Fragen

Kostet sauberer Code nicht erst einmal mehr Zeit?

Beim Schreiben ein wenig, beim Lesen deutlich weniger. Da Code über die Lebensdauer eines Projekts viel häufiger gelesen als geschrieben wird, verschiebt sich die Rechnung schnell, sobald jemand anderes die Stelle anfassen muss.

Gilt das auch für Skripte, die nur einmal laufen?

Nicht im selben Maß. Ein Wegwerfskript darf unordentlich sein, das Problem ist nur, dass solche Skripte erstaunlich oft bleiben. Sobald etwas regelmäßig läuft, gelten die üblichen Regeln.

Wie fange ich in einem Altsystem an?

Nicht mit einem großen Umbau, sondern an der Stelle, an der du ohnehin gerade arbeitest. Sicher die betroffene Stelle mit Tests ab, verbessere Namen und Schnitt dort und lass den Rest zunächst unangetastet.

Persönlich für dich da