Wie Clean Code-Prinzipien Ihr Programmiererlebnis verändern

Code wird einmal geschrieben und hunderte Male gelesen. Der Entwickler, der eine Funktion schreibt, ist selten derjenige, der sie sechs Monate später debuggt, sie für neue Anforderungen erweitert oder ihre Sonderfälle während eines Produktionsvorfalls verstehen muss. Jede Entscheidung beim Schreiben von Code – der Name einer Variable, die Länge einer Funktion, die Struktur einer Klasse – erleichtert oder erschwert die Arbeit des nächsten Lesers. Sauberer Code ist die Disziplin, dies systematisch zu vereinfachen.

Das Konzept wurde von Robert C. Martin, genannt „Uncle Bob“, in seinem Buch „Clean Code: A Handbook of Agile Software Craftsmanship “ (2008) formalisiert, das bis heute als Standardwerk zu diesem Thema gilt. Martin Fowlers „ Refactoring: Improving the Design of Existing Code“ behandelt das komplementäre Problem: Was tun, wenn bestehender Code nicht sauber ist und es werden muss? Zusammen bilden diese beiden Werke die intellektuelle Grundlage für die Clean-Code-Praxis. Dieser Leitfaden erläutert ihre wichtigsten Prinzipien anhand von praktischen Codebeispielen in den gängigsten Programmiersprachen, darunter RPG und PL/I, für Entwickler, die Legacy-Systeme in Unternehmen betreuen.

Was ist sauberer Code?

Sauberer Code ist Quellcode, der leicht lesbar, verständlich, testbar und änderbar ist. Der Begriff „leicht“ bedeutet in diesem Zusammenhang, dass man tatsächlich Arbeit leisten muss. Code, den ein Compiler akzeptiert, ist nicht zwangsläufig sauberer Code. Auch Code, der alle Tests besteht, ist nicht zwangsläufig sauberer Code. Code ist dann sauber, wenn ein anderer Entwickler – jemand, der ihn nicht selbst geschrieben hat – in einem Kontext, der bei seiner Entstehung nicht vorhersehbar war, seine Intention schnell verstehen, ihn sicher modifizieren und ohne unerwartete Folgen erweitern kann.

Martin Fowlers Definition ist die am häufigsten zitierte: „Jeder Narr kann Code schreiben, den ein Computer versteht. Gute Programmierer schreiben Code, den Menschen verstehen.“ Der Maßstab für sauberen Code ist das menschliche Verständnis, nicht die maschinelle Ausführung.

Sauberer Code hat nichts mit Ästhetik zu tun. Es geht nicht darum, einem bestimmten Styleguide um seiner selbst willen zu folgen. Es geht um die strukturellen Eigenschaften des Codes, die bestimmen, wie viel Aufwand jede zukünftige Änderung erfordert. Eine Codebasis, die gegen die Prinzipien von sauberem Code verstößt, häuft kontinuierlich technische Schulden an – die kumulativen Kosten vergangener Abkürzungen –, bis jede neue Funktion das Verständnis und die sorgfältige Navigation der bestehenden Komplexität erfordert, bevor überhaupt etwas Neues hinzugefügt werden kann.

Prinzipien für sauberen Code: Kurzübersicht

Robert C. Martins Prinzipien für sauberen Code lassen sich als eine Reihe praktischer Richtlinien zusammenfassen. Die folgende Tabelle ordnet jedes Prinzip seiner Kernregel und dem Problem zu, das es verhindert:

Prinzip	Kernregel	Problem, das es verhindert
Bedeutungsvolle Namen	Namen sollten Absicht, Variablen, Funktionen und Klassen erkennen lassen.	Kognitiver Aufwand beim Dekodieren dessen x, tmpden obj stellt tatsächlich dar
Kleine Funktionen	Funktionen haben eine Aufgabe: Sie passen auf einen Bildschirm.	Unprüfbare, unlesbare Monolithen, die Verantwortlichkeiten vermischen
Einzelverantwortung	Jede Klasse/jedes Modul hat einen Grund für die Änderung	Gottesklassen, die kaputtgehen, wenn sich eines von einem Dutzend unabhängiger Dinge ändert
DRY (Wiederhole dich nicht)	Jedes Wissen hat eine Repräsentation	Fehlerbehebungen wurden in einer Kopie angewendet, in anderen jedoch nicht; Logikabweichung
KISS (Keep It Simple)	Bevorzugen Sie die einfachste Lösung, die funktioniert.	Überkomplizierter Code, der Probleme löst, die niemand hat
YAGNI (Du wirst es nicht brauchen)	Entwickeln Sie Funktionen erst dann, wenn sie benötigt werden.	Toter, spekulativer Code, der die Komplexität erhöht, ohne Nutzen zu bringen.
Offen/Geschlossen-Prinzip	Erweiterung möglich, Änderungen nicht möglich	Code, der bestehendes Verhalten beim Hinzufügen neuen Verhaltens beeinträchtigt
Trennung von Bedenken	Unterschiedliche Verantwortlichkeiten an unterschiedlichen Orten	Verwickelter Code, bei dem die Änderung einer Sache andere Dinge beeinträchtigt.
Vermeiden Sie Kommentare mit der Frage „Was?“, sondern nutzen Sie sie, um zu erklären, warum.	Der Code erklärt das Was; die Kommentare erklären das Warum.	Veraltete Kommentare, die mehr irreführen als informieren.
Pfadfinderregel	Hinterlassen Sie den Code sauberer, als Sie ihn vorgefunden haben.	Allmählicher Qualitätsverfall durch schrittweise Vernachlässigung

Die wichtigsten Prinzipien für sauberen Code erklärt

DRY, Don't Repeat Yourself

Das DRY-Prinzip besagt, dass jedes Wissen innerhalb eines Systems nur eine einzige, eindeutige und maßgebliche Repräsentation haben darf. Wenn dieselbe Logik an mehreren Stellen vorkommt, weichen diese Repräsentationen zwangsläufig voneinander ab. Eine Änderung einer Geschäftsregel wird so zu einer Suche und Ersetzung in mehreren Dateien, und das Fehlen einer Kopie führt zu einem Fehler.

Das DRY-Prinzip gilt nicht nur für kopierten Code. Es gilt auch für Konfigurationen, Dokumentationen und Datenschemata. Wenn dieselben Informationen an zwei Stellen gepflegt werden müssen, verstoßen Sie gegen das DRY-Prinzip, unabhängig davon, ob Code wörtlich kopiert wurde.

KISS – Keep It Simple

KISS argumentiert, dass Systeme am besten funktionieren, wenn sie einfach gehalten sind, und dass Einfachheit ein primäres Designziel sein sollte. Komplexität ist kein Zeichen von Raffinesse, sondern ein Hinweis darauf, dass etwas hätte klarer ausgedrückt werden können.

Die praktische Konsequenz: Wenn zwei Lösungen dasselbe Problem lösen, ist die einfachere vorzuziehen. Die komplexere Lösung könnte Randfälle abdecken, die Ihnen noch nicht begegnet sind. Sie macht den Code aber definitiv schwerer verständlich für alle, die ihn verwenden.

YAGNI, du wirst es nicht brauchen

YAGNI rät davon ab, Funktionen hinzuzufügen, solange sie nicht benötigt werden. Es ist eine Reaktion auf den weit verbreiteten Impuls, flexible, erweiterbare Systeme für vermeintlich zukünftige Anforderungen zu entwickeln, die sich nie realisieren. Jede Abstraktion, Schnittstelle und Konfigurationsoption, die für einen hypothetischen zukünftigen Anwendungsfall existiert, bedeutet kognitiven Mehraufwand für jeden Entwickler, der den Code heute liest.

Bedeutungsvolle Namen

Namen sind der primäre Kommunikationsmechanismus im Quellcode. Eine Funktion namens process() Sie teilt keinerlei Informationen darüber mit, was sie verarbeitet, wann sie es tut oder was sie zurückgibt. Eine Funktion namens calculateMonthlyInterest() kommuniziert präzise.

Die wichtigsten Kriterien für einen Namen: Lässt sich seine Bedeutung erkennen, ohne die Implementierung zu lesen? Gibt der Name Aufschluss über Zweck, Parameter und Rückgabewert? Wäre ein Kommentar zur Erklärung der Funktion erforderlich?

Kleine Funktionen

Robert C. Martins Faustregel lautet: Funktionen sollten klein sein, kleiner als man für nötig hält. Eine Funktion, die nur eine Aufgabe erfüllt, kann klar benannt, isoliert getestet und ohne Kenntnis ihrer Implementierung verstanden werden. Eine Funktion, die mehrere Aufgaben erfüllt, erfordert hingegen das gleichzeitige Verständnis all dieser Aufgaben.

Das Prinzip der Einzelverantwortung gilt für Funktionen: Eine Funktion sollte eine Aufgabe erfüllen, diese gut erfüllen und ausschließlich diese Aufgabe erfüllen. Benötigt man das Wort „und“, um die Funktion einer Funktion zu beschreiben, erfüllt sie wahrscheinlich zu viele Aufgaben.

Sauberer Code in Java

Die Ausführlichkeit von Java macht saubere Programmierung besonders wichtig. Der vom Programm vorgegebene Boilerplate-Code kann die eigentliche Absicht des Codes verschleiern, wenn er nicht sorgfältig verwaltet wird.

Java

// Before: unclear names, mixed responsibilities, magic numbers
public double calc(int x, int y) {
    double r = 0;
    if (y > 1000) {
        r = x * y * 0.1;
    } else {
        r = x * y * 0.05;
    }
    return r;
}

// After: meaningful names, single responsibility, named constants
private static final double PREMIUM_DISCOUNT_RATE = 0.10;
private static final double STANDARD_DISCOUNT_RATE = 0.05;
private static final int PREMIUM_THRESHOLD = 1000;

public double calculateDiscount(int quantity, int unitPrice) {
    double subtotal = quantity * unitPrice;
    return isPremiumOrder(unitPrice) 
        ? subtotal * PREMIUM_DISCOUNT_RATE 
        : subtotal * STANDARD_DISCOUNT_RATE;
}

private boolean isPremiumOrder(int unitPrice) {
    return unitPrice > PREMIUM_THRESHOLD;
}

Wichtige Best Practices für sauberen Java-Code: Komposition der Vererbung vorziehen, Datenströme anstelle umständlicher Schleifen für die Datenverarbeitung nutzen, magische Zahlen in benannte Konstanten auslagern und Klassen auf eine einzige Aufgabe konzentrieren. Robert C. Martins Prinzipien für sauberen Java-Code beinhalten die Regel, dass Klassen klein sein sollten, gemessen nicht in Zeilen, sondern in Verantwortlichkeiten.

Java

// Clean Java: streams over imperative loops
List<String> activeUserEmails = users.stream()
    .filter(User::isActive)
    .map(User::getEmail)
    .collect(Collectors.toList());

Sauberer Code in Python

Die Designphilosophie von Python – explizit ist besser als implizit, einfach ist besser als komplex – deckt sich nahtlos mit den Prinzipien von sauberem Code. PEP 8 ist der offizielle Styleguide von Python und die Grundlage für sauberen Python-Code.

python

# Before: vague names, long function, no separation
def do_stuff(d):
    res = []
    for i in d:
        if i['a'] > 18:
            res.append(i['n'].upper())
    return res

# After: meaningful names, separated concerns, Pythonic style
def get_adult_names_uppercase(users: list[dict]) -> list[str]:
    return [
        user["name"].upper()
        for user in users
        if user["age"] > 18
    ]

python

# Clean Python: context managers for resource handling
# Before: manual, error-prone
f = open("data.txt")
data = f.read()
f.close()

# After: guaranteed cleanup, self-documenting intent
with open("data.txt") as f:
    data = f.read()

Pythonischer Clean Code verwendet List Comprehensions anstelle von manuellen Schleifen für einfache Transformationen, Typhinweise für selbstdokumentierende Funktionssignaturen, Kontextmanager für die Ressourcenverwaltung und Datenklassen oder benannte Tupel anstelle von einfachen Wörterbüchern für strukturierte Daten.

Sauberer Code in JavaScript und TypeScript

Die Flexibilität von JavaScript ist sowohl seine Stärke als auch seine größte Herausforderung für sauberen Code. Ohne Disziplin sammeln sich in JavaScript-Codebasen inkonsistente Muster, implizite Typumwandlungen und verwickelte Callback-Ketten an.

Javascript

// Before: var, callback hell, no error handling
function getUser(id, cb) {
    db.query('SELECT * FROM users WHERE id = ' + id, function(err, rows) {
        if (err) cb(err);
        cb(null, rows[0]);
    });
}

// After: async/await, parameterized query, proper error handling
async function getUserById(userId: number): Promise<User | null> {
    const [rows] = await db.execute(
        'SELECT * FROM users WHERE id = ?',
        [userId]
    );
    return rows[0] ?? null;
}

Typoskript

// Clean TypeScript: explicit types replace implicit any
// Before
function process(data) {
    return data.map(x => x.v * 2);
}

// After
interface DataPoint {
    value: number;
    label: string;
}

function doubleValues(dataPoints: DataPoint[]): number[] {
    return dataPoints.map(point => point.value * 2);
}

Clean JavaScript verwendet const standardmäßig, let wenn eine erneute Bindung erforderlich ist, und niemals varReine Funktionen, die bei gleichem Input immer den gleichen Output erzeugen und keine Seiteneffekte haben, sind der sauberste Baustein für die JavaScript-Logik.

Sauberer Code in C#

C# bietet leistungsstarke Funktionen für das Schreiben von sauberem, ausdrucksstarkem Code. Die Weiterentwicklung der Sprache – LINQ, Records, Pattern Matching, Nullable Reference Types – zielt kontinuierlich auf eine deklarativere und lesbarere Syntax ab.

scharf

// Before: magic numbers, verbose loop, mutable state
public double CalculateTotal(List<OrderItem> items)
{
    double total = 0;
    foreach (var item in items)
    {
        if (item.Quantity > 10)
            total += item.UnitPrice * item.Quantity * 0.9;
        else
            total += item.UnitPrice * item.Quantity;
    }
    return total;
}

// After: named constant, LINQ, single expression
private const double BulkDiscountRate = 0.9;
private const int BulkDiscountThreshold = 10;

public double CalculateTotal(IEnumerable<OrderItem> items) =>
    items.Sum(item => item.Quantity > BulkDiscountThreshold
        ? item.UnitPrice * item.Quantity * BulkDiscountRate
        : item.UnitPrice * item.Quantity);

C#-Prinzipien für sauberen Code: Verwenden Sie Eigenschaften anstelle von öffentlichen Feldern zur Kapselung, nutzen Sie LINQ für deklarative Datenoperationen, verwenden Sie Datensätze für unveränderliche Datenstrukturen, bevorzugen Sie Schnittstellen gegenüber konkreten Typen in Methodensignaturen und verwenden Sie nullable Referenztypen.string? vs string) um die Nullsicherheit explizit zu machen.

Sauberer Code in Kotlin

Das Design von Kotlin reduziert gezielt den Boilerplate-Code, der Java so schwer sauber zu halten macht, und fügt gleichzeitig Funktionen wie Datenklassen, Erweiterungsfunktionen und Nullsicherheit hinzu, die sauberen Code auf natürliche Weise unterstützen.

Kotlin

// Before: verbose Java-style Kotlin
class User {
    var name: String = ""
    var email: String = ""
    var age: Int = 0
}

fun processUsers(users: List<User>): List<String> {
    val result = mutableListOf<String>()
    for (user in users) {
        if (user.age >= 18) {
            result.add(user.email)
        }
    }
    return result
}

// After: idiomatic clean Kotlin
data class User(val name: String, val email: String, val age: Int)

fun getAdultEmails(users: List<User>): List<String> =
    users.filter { it.age >= 18 }.map { it.email }

Kotlins data class Es stellt automatisch equals, hashCode, copy und toString bereit und eliminiert so den Boilerplate-Code, der Java-Datenklassen umständlich und fehleranfällig macht. Erweiterungsfunktionen ermöglichen das Hinzufügen übersichtlicher Hilfsmethoden zu bestehenden Klassen ohne Vererbung.

Sauberer Code in RPG und PL/I: Legacy-Sprachen, moderne Prinzipien

Die Prinzipien von sauberem Code gelten für jede Programmiersprache, einschließlich der Enterprise-Sprachen, die Finanzsysteme, Versicherungsplattformen und Regierungsanwendungen weltweit betreiben. RPG (Report Program Generator) und PL/I werden in vielen Organisationen weiterhin aktiv gepflegt, und dieselbe Disziplin, die Java oder Python sauber macht, sorgt auch für die Zukunftsfähigkeit von RPG und PL/I.

Sauberer Code in RPG (ILE RPG) :

RPG

     // Before: cryptic two-character names, magic numbers
     C                   EVAL      D = Q * P * 1.05
     C                   IF        Q > 100
     C                   EVAL      D = Q * P * 0.95
     C                   ENDIF

     // After: meaningful names, named constants, clear intent
      /free
       dcl-c BULK_DISCOUNT_THRESHOLD 100;
       dcl-c BULK_DISCOUNT_RATE      0.95;
       dcl-c STANDARD_RATE          1.05;

       dcl-proc CalculateOrderTotal;
         dcl-pi *N packed(15:2);
           quantity  packed(7:0) value;
           unitPrice packed(9:2) value;
         end-pi;

         if quantity > BULK_DISCOUNT_THRESHOLD;
           return quantity * unitPrice * BULK_DISCOUNT_RATE;
         else;
           return quantity * unitPrice * STANDARD_RATE;
         endif;
       end-proc;
      /end-free

Wichtige Praktiken für sauberes Rollenspiel: Verwenden Sie das freie Format von ILE RPG (/freeVerwenden Sie eine Syntax anstelle eines festen Formats, um die Lesbarkeit zu verbessern, benennen Sie Prozeduren beschreibend und ersetzen Sie fest codierte Werte durch benannte Konstanten. dcl-cund zerlegen Sie lange Programme in fokussierte Prozeduren mithilfe von dcl-proc.

Sauberer Code in PL/I :

Biegung

/* Before: single-letter names, no structure */
CALC: PROC(X, Y) RETURNS(FLOAT);
  DCL (X, Y, R) FLOAT;
  IF Y > 1000 THEN R = X * Y * 0.1;
  ELSE R = X * Y * 0.05;
  RETURN(R);
END CALC;

/* After: meaningful names, named constants, clear intent */
DCL PREMIUM_THRESHOLD  FIXED DECIMAL(7) INIT(1000);
DCL PREMIUM_RATE       FLOAT           INIT(0.10);
DCL STANDARD_RATE      FLOAT           INIT(0.05);

CALCULATE_DISCOUNT: PROC(QUANTITY, UNIT_PRICE) RETURNS(FLOAT);
  DCL (QUANTITY, UNIT_PRICE) FLOAT;
  DCL SUBTOTAL              FLOAT;

  SUBTOTAL = QUANTITY * UNIT_PRICE;

  IF UNIT_PRICE > PREMIUM_THRESHOLD
    THEN RETURN(SUBTOTAL * PREMIUM_RATE);
    ELSE RETURN(SUBTOTAL * STANDARD_RATE);

END CALCULATE_DISCOUNT;

Die Clean-Code-Prinzipien von PL/I spiegeln die moderner Programmiersprachen wider: aussagekräftige Bezeichner (die 31-Zeichen-Grenze von PL/I ist für beschreibende Namen ausreichend), benannte Konstanten anstelle von magischen Zahlen, auf eine einzige Aufgabe fokussierte Prozeduren und explizite Fehlerbehandlung mithilfe des ON-Bedingungssystems.

Tools für sauberen Code und statische Analyse

Die manuelle Anwendung von Clean-Code-Prinzipien durch Code-Reviews ist zwar notwendig, aber im großen Maßstab nicht ausreichend. Statische Analysetools setzen Clean-Code-Metriken automatisch durch und kennzeichnen Verstöße, bevor die Codes zusammengeführt werden.

Werkzeug	Sprachen	Was es durchsetzt
SonarQube / SonarCloud	Über 30 Sprachen	Komplexität, Duplikation, Code-Smells, Sicherheit
Karostil	Javac	Namenskonventionen, Formatierung, Struktur
PMD	Java, Apex	Doppelter Code, ungenutzte Variablen, Komplexität
ESLint + typescript-eslint	JavaScript, TypeScript	Stil, Komplexität, ungenutzter Code, asynchrone Muster
Pylint + Radon	Python	PEP 8, Komplexität, Wartbarkeitsindex
ReSharper	C#	Codestil, redundanter Code, Refactoring-Vorschläge
Clippy	Rest	Redewendungen, häufige Fehler
SMART TS XL	COBOL, RPG, PL/I, Java, Python und mehr	Sprachübergreifende Komplexität, Duplikation, toter Code

Die am häufigsten verwendeten Metriken für sauberen Code, die von Tools gemessen werden: zyklomatische Komplexität (Anzahl der Entscheidungszweige, über 10 ist eine Warnung, über 20 ist kritisch), kognitive Komplexität (wie schwierig der Code zu verstehen ist, eine SonarQube-spezifische Metrik, die die zyklomatische Komplexität zur Messung der Lesbarkeit verbessert) und Duplikationsrate (Prozentsatz des duplizierten Codes, über 3 % erfordern Aufmerksamkeit).

Wie SMART TS XL Sorgt für sauberen Code in unternehmensweiten Codebasen.

Die oben genannten Tools für sauberen Code funktionieren innerhalb einer einzelnen Sprache. In Unternehmensumgebungen, in denen Java-Dienste, Python-Pipelines, COBOL-Batchprogramme, RPG-Module und JCL-Jobstreams nebeneinander existieren, müssen die Verstöße gegen die Richtlinien für sauberen Code jeder Sprache gleichzeitig gemessen werden, und die Beziehungen zwischen Komponenten über verschiedene Sprachen hinweg sind genauso wichtig wie die Qualität innerhalb einer einzelnen Datei.

SMART TS XL statische Code-Analyse Die Metriken für sauberen Code werden gleichzeitig für alle Sprachen in der Umgebung angewendet. Zyklomatische Komplexität, Duplikationsraten, Identifizierung von totem Code und strukturelle Kopplungsmetriken werden für COBOL-Programme mit derselben Methodik wie für Java-Klassen berechnet, wodurch vergleichbare, einheitliche Qualitätsmessungen für das gesamte Anwendungsportfolio entstehen.

Die Auswirkungsanalyse ermöglicht es, Verstöße gegen die Clean-Code-Richtlinien auf Architekturebene zu beheben: Wenn ein COBOL-Abschnitt stark mit Dutzenden anderer Programme verknüpft ist, zeigt die Auswirkungsanalyse exakt, welche Komponenten betroffen sind, bevor mit dem Refactoring begonnen wird. Dadurch wird die Refactoring-Lähmung, die Teams in großen Codebasen häufig erleben, in ein strukturiertes Sanierungsprogramm mit definiertem Umfang umgewandelt.

Die Abhängigkeitsanalyse von Anwendungen identifiziert architektonische Verstöße gegen sauberes Code auf Systemebene: Welche Komponenten haben sich im Unternehmensmaßstab zu übermächtigen Klassen entwickelt? Wo verletzen zirkuläre Abhängigkeiten die Trennung von Belangen über Sprachgrenzen hinweg? Und wo wurde dieselbe Geschäftslogik unabhängig voneinander in mehreren Systemen implementiert, ohne dass die einzelnen Kopien voneinander Kenntnis haben? Dieser sprachübergreifende Verstoß gegen das DRY-Prinzip – die separate Pflege derselben Geschäftsregel in einem COBOL-Programm, einem Java-Dienst und einer Python-Pipeline – ist die kostspieligste Kategorie von Verstößen gegen sauberes Code in Unternehmenssystemen und bleibt für Tools, die nur eine Sprache analysieren, unsichtbar.

Für Teams, die Clean-Code-Prinzipien anwenden während Modernisierung des Altbestands Programme, SMART TS XL bietet die Voranalyse für das Refactoring, die die Arbeit überschaubar macht: Toter Code wird vor Beginn der Konvertierung aus dem Geltungsbereich ausgeschlossen, Komponenten mit der höchsten Komplexität werden für eine prioritäre Bearbeitung identifiziert, und der vollständige Abhängigkeitsgraph steht zur Verfügung, bevor Änderungen vorgenommen werden.

Sauberer Code ist eine Teamdisziplin, keine individuelle Praxis

Die Prinzipien dieses Leitfadens sind leichter gesagt als getan. Jeder einzelne Entwickler kann isoliert betrachtet eine saubere Funktion schreiben. Die Herausforderung besteht darin, sauberen Code teamübergreifend, über die Zeit und in einer wachsenden Codebasis mit wechselnden Mitwirkenden zu gewährleisten. Dies erfordert drei Dinge: gemeinsame Standards, die allen bekannt sind und denen alle zugestimmt haben, Tools, die diese Standards automatisch durchsetzen, und eine Kultur der inkrementellen Verbesserung – die Pfadfinderregel konsequent angewendet, sodass jeder Teil des Codes ein wenig sauberer ist, als er vorgefunden wurde.

Robert C. Martins Formulierung ist nach wie vor die treffendste: „Sauberer Code sieht immer so aus, als wäre er von jemandem geschrieben worden, dem etwas daran liegt.“ Der Beweis dafür ist nicht die Abwesenheit von Fehlern, sondern lesbare Namen, zielgerichtete Funktionen, eine klare Struktur und das Fehlen von Überraschungen. Genau diese Merkmale machen eine Codebasis lohnenswert: Sie ist es wert, bearbeitet, weiterentwickelt und über Jahre und Teamwechsel hinweg gepflegt zu werden – Eigenschaften, die jedes erfolgreiche System mit sich bringt.