Clean Code: Werte, Kopplung und Kohäsion, Code Smells, Prinzipien und Praktiken im Überblick

Clean Code: Werte, Kopplung und Kohäsion, Code Smells, Prinzipien und Praktiken im Überblick

https://bildung.social/@oerinformatik/

https://oer-informatik.de/clean-code

Clean Code, Code Smell, Kopplung, Kohäsion, Wartbarkeit, ISO/IEC 25010, Clean Code Developer, Pfadfinderregel, Refactoring, Code-Review, KI-Assistent

tl/dr; (ca. 28 min Lesezeit): Code, der funktioniert, ist noch lange kein guter Code. Dieser Artikel erklärt, was Clean Code meint, woher der Begriff kommt und welche Werte dahinterstehen, wie Du Kopplung und Kohäsion beurteilst und Code Smells erkennst. Eine Landkarte ordnet die Prinzipien der Artikelreihe den Ebenen Ausdruck, Methode, Klasse, Klassenbeziehung und Entwurf zu; dazu kommen die Praktiken, die Kritik an Clean Code und die Frage, wie Du KI-generierten Code prüfst [AI-Assisted]. (Zuletzt geändert am 10.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über Clean Code: Überblick / Lesbarer Code / Einfach bleiben / Refactoring / Methoden gliedern / Klassen schneiden / Vererbung richtig einsetzen / Erweitern statt ändern / SOLID / Vom Entwurf zum Code

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Ein Programm, das die richtigen Ergebnisse liefert, hat seine wichtigste Aufgabe erfüllt – für heute. Morgen kommt eine neue Versandart dazu, übermorgen ändert sich der Rabatt, und in einem halben Jahr sucht jemand anderes einen Fehler in Deinem Code. Ob das Minuten oder Tage dauert, entscheidet sich nicht an der Frage „Funktioniert es?“, sondern an der Frage „Kann man es verstehen und gefahrlos ändern?“. Genau darum geht es bei Clean Code.

Dieser Artikel ist der Einstieg in die Reihe: Er klärt die Begriffe, ordnet die Prinzipien und Praktiken und zeigt, wo die Grenzen liegen. Die folgenden Artikel nehmen sich die Prinzipien einzeln vor und räumen dabei Schritt für Schritt denselben Code auf. Zum Üben gibt es Übungsaufgaben zu Clean Code.

Die Landkarte zeigt, was Dich erwartet: Werte als Ziel, Prinzipien auf fünf Ebenen und Praktiken für den Arbeitsalltag.

Was ist Clean Code?

Clean Code ist Code, den andere Menschen (und Du selbst in ein paar Monaten) schnell lesen, sicher verstehen und mit vertretbarem Aufwand ändern können. Der Begriff wurde durch das Buch „Clean Code: A Handbook of Agile Software Craftsmanship“ von Robert C. Martin (2008) bekannt. Martin sammelt darin Regeln für Namen, Funktionen, Kommentare, Klassen und Tests und betont die Haltung dahinter: Professionelle Entwickler*innen hinterlassen Code so, dass andere gut damit weiterarbeiten können.

Die Ideen sind älter als das Buch. Kopplung und Kohäsion stammen aus dem strukturierten Entwurf (Structured Design) der 1970er-Jahre, der Begriff Code Smell aus den 1990er-Jahren (Kent Beck und Martin Fowler), und viele Prinzipien wie Don’t Repeat Yourself oder das Open Closed Principle haben eigene Urheber*innen, die in den Artikeln der Reihe jeweils genannt werden.

Im deutschsprachigen Raum haben Ralf Westphal und Stefan Lieser die Ideen Ende 2008 in der Initiative Clean Code Developer (CCD) gesammelt. Sie ordnet Prinzipien und Praktiken nach Werten und schlägt vor, sie Schritt für Schritt einzuüben. Die CCD-Initiative teilt den Stoff dafür in farbige Grade ein; diese Reihe ordnet ihn stattdessen nach dem Vorwissen, das Du für ein Prinzip brauchst.

Funktioniert heißt nicht gut

Die Artikelreihe begleitet ein durchgehendes Beispiel, eine sogenannte Code-Kata: den Bestellabschluss im Onlineshop der CSB-Rad GmbH. Eine Methode berechnet Warenwert, Rabatt, Versandkosten und Mehrwertsteuer, vergibt eine Bestellnummer, verschickt eine Bestätigung und speichert die Bestellung. Der erste Stand besteht alle Tests – und ist trotzdem schwer zu lesen:

Java Python all none

// Auszug aus src/kata/java/stand-01, Klasse Shop
public int[] abschliessen(List<Pos> l, String v, String c, String m, boolean x) {
    int s = 0;
    for (Pos p : l) {
        if (p.m() <= 0) {
            throw new IllegalArgumentException("Fehler");
        }
        s = s + p.p() * p.m();
    }
    // Rabatt
    int r = 0;
    if (c != null && c.equals("KURIER10")) {
        int s2 = 0;
        for (Pos p : l) {
            s2 = s2 + p.p() * p.m();
        }
        r = (s2 * 10 + 50) / 100;
    }
    // ... weitere 60 Zeilen: Versand, Mehrwertsteuer, Nummer, Mail, Speichern
}

# Auszug aus src/kata/python/stand-01, Klasse Shop
def abschliessen(self, l: list[Pos], v: str, c: str | None, m: str, x: bool) -> list[int]:
    s = 0
    for p in l:
        if p.m <= 0:
            raise ValueError("Fehler")
        s = s + p.p * p.m
    # Rabatt
    r = 0
    if c is not None and c == "KURIER10":
        s2 = 0
        for p in l:
            s2 = s2 + p.p * p.m
        r = (s2 * 10 + 50) // 100
    # ... weitere 60 Zeilen: Versand, Mehrwertsteuer, Nummer, Mail, Speichern

Was sind l, v, c, m und x? Wofür steht die 10, wofür die 50? Warum wird der Warenwert zweimal berechnet? Und was macht der Parameter x, den der Ausschnitt gar nicht benutzt? Wer hier eine neue Versandart einbauen soll, muss erst den ganzen Code entschlüsseln und läuft Gefahr, beim Ändern etwas anderes kaputt zu machen. Der Code ist korrekt, aber nicht wandelbar. Den vollständigen Code aller Stände findest Du im Ordner src/kata des Repositorys zu dieser Reihe.

Die Werte hinter Clean Code

Prinzipien sind Werkzeuge, kein Selbstzweck. Die CCD-Initiative nennt vier Werte, an denen sich jedes Prinzip messen lassen muss:

Wandelbarkeit ist der Wert, den man am leichtesten opfert: Unter Zeitdruck zählt, dass es heute läuft. Die Kosten zeigen sich erst später, wenn jede Änderung länger dauert. Für diesen Effekt hat Ward Cunningham 1992 den Begriff technische Schulden (technical debt) geprägt: Unsauberer Code ist wie ein Kredit, für den bei jeder späteren Änderung Zinsen fällig werden.

Clean Code und Wartbarkeit nach ISO/IEC 25010

Die Norm ISO/IEC 25010 beschreibt die Produktqualität von Software mit Qualitätsmerkmalen (mehr dazu im Artikel Softwarequalität nach ISO/IEC 25010). Clean Code zahlt vor allem auf das Merkmal Wartbarkeit (Maintainability) ein, also darauf, wie wirksam und effizient sich ein Produkt ändern lässt. Die Teilmerkmale der Wartbarkeit passen genau zu den Themen dieser Reihe:

Clean Code ist damit keine Geschmacksfrage, sondern eine Maßnahme der konstruktiven Qualitätssicherung: Sie soll Fehler und Änderungsaufwand vermeiden, bevor sie entstehen. Andere Merkmale wie Benutzbarkeit oder Leistungseffizienz berührt Clean Code nur am Rand – manchmal sogar im Konflikt (siehe Abschnitt „Kritik an Clean Code“).

Kopplung und Kohäsion: die zwei Grundgrößen

Fast alle Prinzipien der Reihe lassen sich auf zwei Begriffe zurückführen, die Wayne P. Stevens, Glenford J. Myers und Larry L. Constantine 1974 im Aufsatz „Structured Design“ (IBM Systems Journal) beschrieben haben:

• Kopplung (coupling) beschreibt, wie stark ein Baustein (Methode, Klasse, Paket) von anderen Bausteinen abhängt. Je mehr ein Baustein über das Innere eines anderen wissen muss, desto enger ist die Kopplung.

• Kohäsion (cohesion) beschreibt, wie stark die Teile eines Bausteins zusammengehören. Eine Klasse hat hohe Kohäsion, wenn ihre Attribute und Methoden gemeinsam eine Aufgabe erfüllen.

Das Ziel lautet: lose Kopplung, hohe Kohäsion (low coupling, high cohesion). Dann wirkt sich eine Änderung nur auf einen Baustein aus, und dieser Baustein ist leicht zu verstehen, weil alles darin zusammengehört.

Die Skizze zeigt beide Größen zusammen: Links greift der Bestellabschluss auf alles zu, eine Hilfsklasse ShopHelfer sammelt Methoden, die nichts miteinander zu tun haben (Geldbeträge formatieren, E-Mail-Adressen prüfen, Versandkosten berechnen), und die Daten der Bestellung sind öffentlich. Rechts kümmert sich jede Klasse um eine Sache, und zwischen den Klassen gibt es nur wenige, klar benannte Abhängigkeiten.

Beispiel: Versandkosten aus dem Inneren der Bestellung

Im folgenden Ausschnitt berechnet ein Versandkostenrechner die Paketkosten (vereinfacht, ohne Freigrenze): 6,90 € je angefangene 31,5 kg. Dazu läuft er selbst durch die Positionen der Bestellung und rechnet das Gewicht zusammen:

Java Python all none

import java.util.List;

record Position(String artikelnr, int nettopreisCent, int menge, int gewichtGramm) {}

class Bestellung {
    List<Position> positionen;   // Liste ist von außen direkt erreichbar

    Bestellung(List<Position> positionen) {
        this.positionen = positionen;
    }
}

class Versandkostenrechner {
    int paketkostenCent(Bestellung bestellung) {
        int gewicht = 0;
        for (Position p : bestellung.positionen) {   // greift in das Innere der Bestellung
            gewicht += p.gewichtGramm() * p.menge();
        }
        int pakete = Math.max(1, (gewicht + 31499) / 31500);   // aufrunden auf angefangene Pakete
        return pakete * 690;
    }
}

from dataclasses import dataclass


@dataclass(frozen=True)
class Position:
    artikelnr: str
    nettopreis_cent: int
    menge: int
    gewicht_gramm: int


class Bestellung:
    def __init__(self, positionen: list[Position]) -> None:
        self.positionen = positionen   # Liste ist von außen direkt erreichbar


class Versandkostenrechner:
    def paketkosten_cent(self, bestellung: Bestellung) -> int:
        gewicht = 0
        for p in bestellung.positionen:            # greift in das Innere der Bestellung
            gewicht += p.gewicht_gramm * p.menge
        pakete = max(1, -(-gewicht // 31500))      # aufrunden auf angefangene Pakete
        return pakete * 690

Der Rechner ist eng an die Bestellung gekoppelt: Er weiß, dass die Positionen in einer Liste liegen, wie eine Position aufgebaut ist und wie man das Gewicht aus Menge und Einzelgewicht bildet. Ändert sich eine dieser Einzelheiten (etwa weil Räder künftig mit Verpackungsgewicht gerechnet werden), muss auch der Rechner geändert werden. Gleichzeitig fehlt der Bestellung eine Fähigkeit, die eigentlich zu ihr gehört. Wenn eine Methode mehr mit den Daten einer anderen Klasse arbeitet als mit den eigenen, spricht man vom Smell Feature Envy (siehe unten).

Nach dem Umbau berechnet die Bestellung ihr Gesamtgewicht selbst; der Rechner fragt nur noch danach:

Java Python all none

import java.util.List;

record Position(String artikelnr, int nettopreisCent, int menge, int gewichtGramm) {}

class Bestellung {
    private final List<Position> positionen;

    Bestellung(List<Position> positionen) {
        this.positionen = List.copyOf(positionen);
    }

    int gesamtgewichtGramm() {
        int gewicht = 0;
        for (Position p : positionen) {
            gewicht += p.gewichtGramm() * p.menge();
        }
        return gewicht;
    }
}

class Versandkostenrechner {
    private static final int PAKETGEWICHT_GRAMM = 31_500;
    private static final int PAKETPREIS_CENT = 690;

    int paketkostenCent(Bestellung bestellung) {
        int gewicht = bestellung.gesamtgewichtGramm();
        int pakete = Math.max(1, (gewicht + PAKETGEWICHT_GRAMM - 1) / PAKETGEWICHT_GRAMM);   // aufrunden
        return pakete * PAKETPREIS_CENT;
    }
}

from dataclasses import dataclass


@dataclass(frozen=True)
class Position:
    artikelnr: str
    nettopreis_cent: int
    menge: int
    gewicht_gramm: int


class Bestellung:
    def __init__(self, positionen: list[Position]) -> None:
        self._positionen = list(positionen)        # Unterstrich: nur für die Klasse selbst

    def gesamtgewicht_gramm(self) -> int:
        return sum(p.gewicht_gramm * p.menge for p in self._positionen)


class Versandkostenrechner:
    PAKETGEWICHT_GRAMM = 31_500
    PAKETPREIS_CENT = 690

    def paketkosten_cent(self, bestellung: Bestellung) -> int:
        gewicht = bestellung.gesamtgewicht_gramm()
        pakete = max(1, -(-gewicht // self.PAKETGEWICHT_GRAMM))  # aufrunden
        return pakete * self.PAKETPREIS_CENT

Jetzt hängt der Rechner nur noch von einer einzigen Operation der Bestellung ab, und die Liste der Positionen ist privat. Die Bestellung ist kohäsiver geworden, weil das Gewicht dort berechnet wird, wo die Daten liegen. Die beiden Konstanten machen außerdem die Zahlen 690 und 31500 verständlich. Beide Fassungen liefern dieselben Ergebnisse, etwa 6,90 € für ein Lichtset (350 g) und 13,80 € für 25 Bügelschlösser (32,5 kg, also zwei Pakete).

Kopplung und Kohäsion beurteilen

Um zwei Entwürfe zu vergleichen, helfen ein paar Fragen:

Die Fachliteratur unterscheidet außerdem Arten von Kopplung und Kohäsion. Am schwächsten ist die zufällige Kohäsion (coincidental cohesion), bei der Teile nur deshalb zusammenstehen, weil irgendwo Platz war (typisch: Klassen mit Namen wie Helfer, Utils oder Manager). Am stärksten ist die funktionale Kohäsion, bei der alle Teile genau eine Aufgabe erfüllen. Bei der Kopplung ist die Datenkopplung (nur einfache Werte werden übergeben) am losesten, die Inhaltskopplung (ein Baustein greift direkt auf die Interna eines anderen zu) am engsten.

Grenzen: Keine Kopplung gibt es nicht, denn Bausteine müssen zusammenarbeiten. Ziel ist eine bewusste, sichtbare und möglichst schmale Kopplung. Wer jede Abhängigkeit hinter weiteren Schnittstellen versteckt, schafft neue Komplexität; dieser Zielkonflikt begegnet Dir in den Artikeln Einfach bleiben und SOLID wieder.

In Java und Python

Die Beispiele sehen in beiden Sprachen ähnlich aus, an einigen Stellen arbeiten die Sprachen aber verschieden:

• Sichtbarkeit: Java erzwingt private; der Compiler verbietet den Zugriff von außen. Python kennt keine echte Sichtbarkeit. Ein führender Unterstrich (_positionen) ist eine Konvention: „nicht von außen benutzen“. Werkzeuge der statischen Codeanalyse warnen bei Verstößen, verhindern sie aber nicht.

• Datenklassen: Java bildet unveränderliche Datenobjekte mit record, Python mit @dataclass(frozen=True).

• Kopien: List.copyOf(...) (Java) bzw. list(...) (Python) legt eine eigene Liste an, damit niemand die Positionen nachträglich von außen verändern kann.

• Typen: Java prüft Typen beim Übersetzen. In Python sind die Typannotationen (list[Position], int) Hinweise, die erst ein Werkzeug wie mypy prüft.

Code Smells: Hinweise auf unsauberen Code

Ein Code Smell (übel riechender Code) ist ein Merkmal im Code, das auf ein tieferliegendes Problem im Entwurf hindeutet. Der Begriff stammt von Kent Beck und wurde durch Martin Fowlers Buch „Refactoring“ (1999, 2. Auflage 2018) bekannt, in dem Beck und Fowler einen Katalog von Smells mit passenden Umbauten zusammengestellt haben. Ein Smell ist kein Fehler: Der Code funktioniert. Er ist ein Anlass, genauer hinzuschauen.

Die englischen Namen folgen der 2. Auflage von „Refactoring“. Die magischen Zahlen stehen dort nicht als eigener Smell, sondern als Umbau „Replace Magic Literal“; im Alltag spricht man trotzdem meist vom Smell „Magic Number“. Auch Kommentare führt Fowler als Smell, wenn sie unklaren Code erklären müssen, statt dass der Code selbst klar ist.

Smells helfen beim Lesen fremden Codes und bei Reviews: Statt „gefällt mir nicht“ kannst Du benennen, was Dich stört, und den passenden Umbau vorschlagen. Wie Du Smells in kleinen, durch Tests abgesicherten Schritten beseitigst, zeigt der Artikel Refactoring.

Landkarte der Prinzipien

Die Prinzipien der Reihe wirken auf unterschiedlichen Ebenen: Manche betreffen einen einzelnen Ausdruck oder Namen, andere das Zusammenspiel ganzer Klassen oder den Entwurf vor dem ersten Code. Die Tabelle ordnet sie ein und nennt den Artikel, in dem sie ausführlich behandelt werden.

Die Ebenen bauen aufeinander auf: Ein Klassenentwurf nach dem Open Closed Principle hilft wenig, wenn die Methoden darin unlesbar sind. Deshalb beginnt die Reihe beim Ausdruck und arbeitet sich nach oben zum Entwurf vor. Dazwischen steht der Artikel Refactoring: Er zeigt, wie Du Code Smells in kleinen, durch Tests abgesicherten Schritten beseitigst, und ist die Grundlage für alle weiteren Umbauten der Kata. Die Zuordnung ist nicht starr: YAGNI etwa gilt für eine einzelne Zeile ebenso wie für eine ganze Architektur.

Praktiken: Clean Code im Arbeitsalltag

Prinzipien sagen, wie guter Code aussieht. Praktiken sorgen dafür, dass er im Team auch entsteht und erhalten bleibt.

Die Pfadfinderregel hat Robert C. Martin in „Clean Code“ populär gemacht; er bezieht sich auf einen Grundsatz der Pfadfinderbewegung, den Lagerplatz sauberer zu verlassen, als man ihn vorgefunden hat. Wichtig ist das Maß: Aufräumen in kleinen Schritten, die zur aktuellen Aufgabe passen und durch Tests abgesichert sind.

Weiterlernen: Lesen, Austausch, Erfahrung teilen

Clean Code lernst Du nicht an einem Nachmittag. Die CCD-Initiative empfiehlt deshalb auch Praktiken, die eher Haltung als Technik sind:

• Lesen: Fachbücher, Blogs und vor allem fremden Code lesen, etwa in Open-Source-Projekten.

• Fachveranstaltungen besuchen: Meetups, Konferenzen und offene Formate wie Unkonferenzen zeigen, wie andere Teams arbeiten.

• Erfahrung teilen: im Pair Programming, in Reviews oder in einem Coding Dojo, in dem eine Gruppe gemeinsam eine Kata löst.

• Reflektieren: Nach einer Aufgabe kurz notieren, was gut ging und was Du beim nächsten Mal anders machen würdest.

Kritik an Clean Code

Clean Code ist weit verbreitet, aber nicht unumstritten. Vier Kritikpunkte tauchen immer wieder auf:

• Dogmatismus: Regeln wie „Funktionen sollen sehr kurz sein“ oder „Kommentare sind ein Zeichen von Versagen“ werden manchmal wie Gesetze behandelt. Dann wird umgebaut, weil eine Regel es verlangt, nicht weil der Code dadurch besser wird.

• Kleinteilige Methoden: Martin empfiehlt sehr kurze Funktionen. John Ousterhout hält in „A Philosophy of Software Design“ (2018) dagegen, dass viele winzige Methoden und Klassen den Code zersplittern: Wer einen Ablauf verstehen will, muss dann durch Dutzende Dateien springen. Er bevorzugt „tiefe“ Module mit einfacher Schnittstelle und viel Funktionalität dahinter.

• Performance: Casey Muratori hat 2023 im Beitrag „Clean Code, Horrible Performance“ gemessen, dass ein Beispiel mit Polymorphie und kleinen Funktionen um ein Vielfaches langsamer lief als eine Fassung mit switch und zusammengefassten Daten. In rechenintensiven Programmteilen (Spiele, Signalverarbeitung, große Datenmengen) kann das entscheidend sein.

• Subjektivität: Was „lesbar“ ist, hängt von Erfahrung, Sprache und Teamkonventionen ab. Viele Regeln lassen sich nicht messen, und Streit über Geschmacksfragen kostet Zeit.

Wie gehst Du damit um? Eine ausgewogene Stellungnahme erkennt die Kritik an und zieht Grenzen: Die Prinzipien sind Heuristiken, keine Gesetze. Sie lohnen sich dort, wo Code lange lebt und oft geändert wird, also in den meisten Geschäftsanwendungen. Wo Laufzeit messbar zählt, wird gezielt optimiert, aber erst nach dem Messen und nur an den Stellen, die es brauchen (Beware of Premature Optimization). Gegen Subjektivität helfen gemeinsame Teamkonventionen, automatische Prüfungen und Reviews, in denen Ihr Smells und Werte als gemeinsame Sprache nutzt. Und jedes Prinzip muss sich an den Werten messen lassen: Macht ein Umbau den Code wandelbarer, korrekter oder die Arbeit effizienter? Wenn nicht, ist er überflüssig.

Clean Code und KI-Assistenten

KI-Assistenten erzeugen in Sekunden Code, der plausibel aussieht und oft funktioniert. Damit verschiebt sich Deine Rolle: Du schreibst weniger selbst, musst aber mehr lesen und beurteilen. Für KI-generierten Code gelten dieselben Maßstäbe wie für Code von Kolleg*innen, mit einigen typischen Schwachstellen:

• KI-Code ist oft lokal plausibel, aber nicht eingebettet: Er erfindet eine Hilfsmethode neu, die es im Projekt schon gibt (doppelter Code), oder benutzt andere Namen als der Rest des Projekts.

• Er behandelt Randfälle häufig unvollständig (leere Listen, Grenzwerte, Rundung), weil die fachlichen Regeln nur im Prompt oder gar nicht stehen.

• Er kann Bibliotheken, Methoden oder Parameter erfinden, die es nicht gibt, oder veraltete Schnittstellen verwenden.

• Er neigt zu zu viel Code: zusätzliche Optionen, Konfigurationen und Abstraktionen, die niemand verlangt hat (YAGNI).

• Er kann Sicherheitslücken enthalten, etwa fest eingetragene Zugangsdaten oder ungeprüfte Eingaben.

Daraus ergeben sich Fragen für das Review:

Hilfreich ist außerdem, KI-Vorschläge in kleinen Schritten zu übernehmen und jeden Schritt einzeln zu committen. So bleibt nachvollziehbar, welche Änderung woher kommt, und ein misslungener Schritt lässt sich leicht zurücknehmen. Die Verantwortung für den Code bleibt bei Dir und Deinem Team.

Fazit

Clean Code bedeutet, Code für Menschen zu schreiben: für Kolleg*innen und für Dich selbst in einem halben Jahr. Maßstab sind die Werte Wandelbarkeit, Korrektheit, Produktionseffizienz und Reflexion; im Sinne der ISO/IEC 25010 geht es vor allem um Wartbarkeit. Kopplung und Kohäsion sind die Grundgrößen, Code Smells die Warnsignale, die Prinzipien der Reihe die Werkzeuge auf fünf Ebenen und die Praktiken der Rahmen, in dem sauberer Code im Team entsteht. Die Prinzipien sind Heuristiken: Sie verlangen Abwägung, gerade wenn Performance zählt oder KI-Werkzeuge schnell viel Code liefern.

Der nächste Artikel der Reihe beginnt auf der untersten Ebene: Lesbarer Code räumt Namen, Konventionen und Kommentare der Kata auf. Zum Üben gibt es die Übungsaufgaben zu Clean Code.

Leitfragen

1. Warum ist Code, der alle Tests besteht, nicht automatisch guter Code? Antwort

Tests zeigen nur, dass der Code heute das Richtige tut. Ob er sich lesen, verstehen und gefahrlos ändern lässt, prüfen sie nicht; schlechte Namen, Doppelungen und lange Methoden machen jede spätere Änderung teuer und fehleranfällig. siehe Abschnitt „Funktioniert heißt nicht gut“

2. Welche vier Werte stehen hinter Clean Code, und zu welchem Qualitätsmerkmal nach ISO/IEC 25010 trägt Clean Code vor allem bei? Antwort

Wandelbarkeit, Korrektheit, Produktionseffizienz und Reflexion (kontinuierliche Verbesserung). Clean Code zahlt vor allem auf die Wartbarkeit mit ihren Teilmerkmalen Modularität, Wiederverwendbarkeit, Analysierbarkeit, Modifizierbarkeit und Testbarkeit ein. siehe Abschnitt „Die Werte hinter Clean Code“

3. Was bedeuten Kopplung und Kohäsion, und woran erkennst Du, welcher von zwei Entwürfen loser gekoppelt ist? Antwort

Kopplung ist die Abhängigkeit eines Bausteins von anderen, Kohäsion der Zusammenhalt seiner Teile; angestrebt sind lose Kopplung und hohe Kohäsion. Loser gekoppelt ist der Entwurf, dessen Klassen weniger andere Klassen kennen, nur deren Operationen statt deren Daten nutzen und bei Änderungen weniger Folgeänderungen auslösen. siehe Abschnitt „Kopplung und Kohäsion beurteilen“

4. Was ist ein Code Smell, und welche typischen Smells kennst Du? Antwort

Ein Code Smell ist ein Merkmal im Code, das auf ein Entwurfsproblem hindeutet, ohne ein Fehler zu sein. Typisch sind lange Methode, große Klasse, doppelter Code, Feature Envy, magische Zahlen, rätselhafte Namen und lange Parameterlisten. siehe Abschnitt „Code Smells: Hinweise auf unsauberen Code“

5. Auf welchen Ebenen wirken die Prinzipien der Reihe? Nenne je Ebene ein Beispiel. Antwort

Ausdruck (sprechende Namen, POLA), Methode (SLA, IOSP, Fail fast), Klasse (SRP, Information Hiding), Klassenbeziehung (LSP, OCP, ISP, DIP, Law of Demeter) und Entwurf (Design before Implementation, YAGNI); KISS und DRY wirken auf Ausdruck und Methode. siehe Abschnitt „Landkarte der Prinzipien“

6. Welche Praktiken unterstützen Clean Code, und was trägt jede bei? Antwort

Die Pfadfinderregel verbessert den Code bei jeder Änderung ein Stück, Versionsverwaltung macht Änderungen nachvollziehbar und umkehrbar, automatische Tests sichern Umbauten ab, Reviews und statische Codeanalyse finden Smells, CI prüft jede Änderung automatisch, und Reflexion verbessert die Arbeitsweise des Teams. siehe Abschnitt „Praktiken: Clean Code im Arbeitsalltag“

7. Welche Kritik gibt es an Clean Code, und wie lässt sich dazu Stellung nehmen? Antwort

Kritisiert werden Dogmatismus, zu kleinteilige Methoden, Laufzeitnachteile und die Subjektivität vieler Regeln. Eine ausgewogene Stellungnahme behandelt die Prinzipien als Heuristiken, misst sie an den Werten, optimiert nur nach Messung und legt Konventionen im Team fest. siehe Abschnitt „Kritik an Clean Code“

8. Worauf achtest Du beim Review von KI-generiertem Code besonders? Antwort

Du musst jede Zeile verstehen, fachliche Regeln und Randfälle mit Tests prüfen, auf Doppelungen zum vorhandenen Code, erfundene oder fragwürdige Bibliotheken, unnötige Zusatzfunktionen, enge Kopplung sowie Sicherheit und Datenschutz achten. siehe Abschnitt „Clean Code und KI-Assistenten“

Links und weitere Informationen

• für den Einstieg: Clean Code Developer – Werte, Prinzipien und Praktiken

• als Nachschlagewerk: Robert C. Martin: Clean Code. A Handbook of Agile Software Craftsmanship. Prentice Hall 2008

• als Nachschlagewerk: Martin Fowler: Refactoring. Improving the Design of Existing Code. 2. Auflage, Addison-Wesley 2018; Kurzbeschreibung des Begriffs Code Smell bei Martin Fowler

• zur Vertiefung: W. P. Stevens, G. J. Myers, L. L. Constantine: Structured Design. IBM Systems Journal 13 (2), 1974

• als Gegenposition: John Ousterhout: A Philosophy of Software Design. Yaknyam Press 2018; Casey Muratori: „Clean“ Code, Horrible Performance (2023)

• auf oer-informatik.de: Softwarequalität nach ISO/IEC 25010, Teststrategie und Qualitätssicherung, Unit-Tests, Dependency Injection

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Clean Code: Werte, Kopplung und Kohäsion, Code Smells, Prinzipien und Praktiken im Überblick” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/clean-code veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/design-prinzipien/clean-code. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 10.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]