
Clean Code
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
- Für Softwareentwickler und Software Engineers , die ihre Codequalität systematisch verbessern möchten
- Bewährte Best Practices für sauberen, flexiblen und wartbaren Code verständlich erklärt
- Fallstudien, Heuristiken und Code Smells helfen, problematischen Code zu erkennen und gezielt zu refaktorieren
- Zentrale Designprinzipien wie SOLID sowie Techniken für Funktionen, Klassen, Tests und Fehlerbehandlung
- Fokus auf professionelle Entwicklungspraktiken und verantwortungsvolle Softwareentwicklung
More details
Other editions
Additional editions

Previous edition

Persons
Content
- Titelbild
- Titelseite
- Impressum
- Inhaltsverzeichnis
- Vorwort
- Einleitung
- Ein Hinweis zu älteren Kapiteln
- Wie dieses Buch aufgebaut ist
- Einleitung (aus längst vergangenen Zeiten)
- Über den Autor
- Kapitel 1: Sauberer Code
- 1.1 Code, Code und nochmals Code
- 1.2 Schlechter Code
- 1.2.1 Einstellung
- 1.2.2 Das grundlegende Problem
- 1.3 Sauberen Code schreiben - eine Kunst?
- 1.3.1 Was ist sauberer Code?
- 1.4 Das große Ganze
- 1.4.1 Was bringt uns sauberer Code?
- 1.4.2 Produktivität
- 1.4.3 Lebensqualität
- 1.5 Wir lesen mehr, als wir schreiben
- 1.6 Die Pfadfinder-Regel
- Teil I: Code
- Kapitel 2: Halten Sie Ihren Code sauber!
- 2.1 Der Bereinigungsvorgang
- 2.2 Zusammenfassung
- 2.3 Postskriptum: Bob aus der Zukunft spielt mit Grok 3
- 2.4 Zusammenfassung des Postskriptums
- Kapitel 3: Grundlegende Prinzipien
- 3.1 Klein, aussagekräftig benannt, strukturiert und sortiert
- 3.1.1 Funktionen
- 3.2 Ein aussagekräftigeres Beispiel
- 3.2.1 Unabhängige Auslieferbarkeit
- 3.3 Abschließende Bemerkungen
- Kapitel 4: Aussagekräftige Namen
- 4.1 Zweckbeschreibende Namen wählen
- 4.1.1 Ein Namenssystem aufbauen
- 4.1.2 Fehlinformationen vermeiden
- 4.1.3 Unterschiede deutlich machen
- 4.1.4 Aussprechbare Namen verwenden
- 4.1.5 Suchbare Namen verwenden
- 4.1.6 Namen von sinnvoller Länge verwenden
- 4.1.7 Codierungen vermeiden
- 4.1.8 Passende Wortarten verwenden
- 4.1.9 Schlüsselwort-Parameter beachten
- 4.1.10 Keine lustig gemeinten Namen verwenden
- 4.1.11 Ein Wort pro Konzept wählen
- 4.1.12 Namen der Lösungsdomäne verwenden
- 4.1.13 Namen der Problemdomäne verwenden
- 4.1.14 Sinnstiftenden Kontext hinzufügen
- 4.1.15 Keinen überflüssigen Kontext hinzufügen
- 4.2 Abschließende Worte
- Kapitel 5: Kommentare
- 5.1 Unser Scheitern kaschieren
- 5.1.1 Ausgeblendete oder verborgene Kommentare
- 5.1.2 Lügende Kommentare
- 5.1.3 Insider-Kommentare
- 5.1.4 Kommentare sind kein Ersatz für guten Code
- 5.1.5 Erklären Sie Ihre Intention durch den Code
- 5.2 Gute Kommentare
- 5.2.1 Juristische Kommentare
- 5.2.2 Informierende Kommentare
- 5.2.3 Erklärung der Intention
- 5.2.4 Klarstellungen
- 5.2.5 Warnungen vor Konsequenzen
- 5.2.6 Verstärkung
- 5.2.7 Javadocs (und Verwandte) in öffentlichen APIs
- 5.3 Schlechte Kommentare
- 5.3.1 Selbstgespräche
- 5.3.2 Redundante Kommentare
- 5.3.3 Irreführende Kommentare
- 5.3.4 Redundanz und Ungenauigkeit
- 5.3.5 Vorgeschriebene Kommentare
- 5.3.6 Tagebuch-Kommentare
- 5.3.7 Geschwätz
- 5.3.8 Grauenvolles Geschwätz
- 5.3.9 TODO-Kommentare
- 5.3.10 Funktionen oder Variablen anstelle von Kommentaren verwenden
- 5.3.11 Positionsbezeichner
- 5.3.12 Zuschreibungen und Nebenbemerkungen
- 5.3.13 Auskommentierter Code
- 5.3.14 HTML-Kommentare
- 5.3.15 Nicht lokale Informationen
- 5.3.16 Zu viele Informationen
- 5.3.17 Unklarer Zusammenhang
- 5.3.18 Funktionskopf-Kommentare
- 5.3.19 Javadocs in nicht öffentlichem Code
- 5.3.20 Beispiel
- 5.4 Zusammenfassung
- Kapitel 6: Formatierung
- 6.1 Der Zweck der Formatierung
- 6.2 Vertikale Formatierung
- 6.2.1 Vertikaler Weißraum zwischen Konzepten
- 6.2.2 Vertikale Dichte
- 6.2.3 Vertikaler Abstand
- 6.2.4 Variablendeklarationen
- 6.2.5 Abhängige Funktionen
- 6.2.6 Konzeptionelle Affinität
- 6.3 Horizontale Formatierung
- 6.3.1 Horizontaler Weißraum und Dichte
- 6.3.2 Horizontale Ausrichtung
- 6.3.3 Einrückung
- 6.3.4 Einrückungsregeln brechen
- 6.4 Team-Regeln
- 6.5 Uncle Bobs Formatierungsregeln
- Kapitel 7: Saubere Funktionen
- 7.1 Klein!
- 7.1.1 Wohlgeschriebene Prosa
- 7.1.2 Eine Abstraktionsebene pro Funktion
- 7.2 Code von oben nach unten lesen: Stepdown-Regel
- 7.2.1 Kuddelmuddel
- 7.3 Switch-Anweisungen
- 7.4 Saubere Funktionen: Eine genauere Betrachtung
- 7.4.1 Kontextbezogen
- 7.4.2 Benennbar
- 7.4.3 Isoliert
- 7.4.4 Homogen
- 7.4.5 Rein
- 7.5 Zusammenfassung
- Kapitel 8: Heuristiken für Funktionen
- 8.1 Funktionsargumente
- 8.1.1 Variadische Argumente
- 8.1.2 Mehr als drei Argumente?
- 8.1.3 Schlüsselwort-Argumente
- 8.1.4 Flag-Argumente
- 8.1.5 Output-Argumente
- 8.1.6 Fehlercodes
- 8.2 Anweisung und Abfrage trennen
- 8.3 Exceptions sind besser als Fehlercodes
- 8.3.1 Auf eigene Gefahr!
- 8.3.2 try/catch-Blöcke extrahieren
- 8.3.3 Fehler-Handling ist eine Aufgabe
- 8.3.4 Der Abhängigkeitsmagnet von Fehlercodes
- 8.4 DRY: Don't Repeat Yourself
- 8.4.1 Einfacher wiederholter Code
- 8.4.2 Ähnlicher Code
- 8.4.3 Schleifen-Duplizierung
- 8.4.4 Zufällige und essenzielle Duplizierung
- 8.5 Nebeneffekte
- 8.5.1 Wir sind nicht gut darin
- 8.5.2 Funktionale Programmiersprachen
- 8.5.3 Objektorientierte Sprachen
- 8.6 Strukturierte Programmierung
- 8.6.1 Sequenzen
- 8.6.2 Selektionen
- 8.6.3 Iterationen
- 8.7 Wer soll sich das alles merken?
- 8.8 Zusammenfassung
- Kapitel 9: Die saubere Methode
- 9.1 Mach es richtig
- 9.2 Beispiel
- 9.2.1 Design und Architektur berücksichtigen
- 9.3 Zusammenfassung
- Kapitel 10: Eine Aufgabe
- 10.1 Refactoring per Extract-Methode
- 10.1.1 Widerstand ist zwecklos!
- 10.2 Was sind große Funktionen überhaupt?
- 10.3 Extraktion und Klassen
- 10.4 Zusammenfassung
- Kapitel 11: Eine Frage des Respekts
- 11.1 Die Zeitungsmetapher
- 11.1.1 Respektvoll schreiben
- 11.2 Die Stepdown-Regel: »Hello again«
- 11.3 Die Abstraktions-Achterbahn
- 11.4 Schreiben und Lesen funktionieren unterschiedlich
- Kapitel 12: Objekte und Datenstrukturen
- 12.1 Was ist ein Objekt?
- 12.2 Datenabstraktion
- 12.3 Daten/Objekt-Antisymmetrie
- 12.4 Das Gesetz von Demeter
- 12.4.1 Train Wreck
- 12.4.2 Hybride
- 12.4.3 Struktur verbergen
- 12.5 Datentransfer-Objekte
- 12.5.1 Das objekt-relationale »Impedance Mismatch«
- 12.5.2 Objekte und Datenstrukturen verwenden
- 12.5.3 switch-Anweisungen
- 12.5.4 Die objektorientierte Lösung
- 12.5.5 Ruhig, Brauner
- 12.6 Kompromiss zwischen objektorientierten und prozeduralen Konzepten
- 12.7 Aber wie sieht es mit der Geschwindigkeit aus?
- 12.8 Zusammenfassung
- Kapitel 13: Saubere Klassen
- 13.1 Klassen und Module im Vergleich zu Dateien
- 13.2 Was sollte eine Klasse enthalten?
- 13.2.1 Klassendesign auf den Punkt gebracht
- 13.2.2 Heuristiken und Charakteristiken
- 13.2.3 Wann ist eine Klasse zu groß?
- 13.2.4 Policys im Code
- 13.2.5 Wo sich Gründe für Veränderungen verbergen
- 13.2.6 Die Lösung
- 13.2.7 Eine übermäßig offene Implementierung
- 13.2.8 Jetzt handeln oder abwarten?
- 13.2.9 Und was jetzt?
- 13.3 Geschlossene, kohäsive Single-Responsibility-Klassen
- 13.3.1 Wenn sich Policys ändern
- 13.3.2 Ist das Overengineering?
- 13.3.3 Einfacheres Testen
- 13.4 Bühne frei für die KI
- 13.4.1 Fehler sind unvermeidlich
- Kapitel 14: Testdisziplinen
- 14.1 Disziplin 1: Test-Driven Development (TDD)
- 14.1.1 Die drei Gesetze des TDD
- 14.2 Disziplin 2: Test && Commit || Revert (TCR)
- 14.3 Disziplin 3: Small Bundles
- 14.4 Design
- 14.5 Disziplin
- 14.5.1 Lästig, langweilig und langsam
- 14.5.2 Debuggen
- 14.5.3 Dokumentation
- 14.5.4 Zuverlässigkeit
- 14.5.5 Design
- 14.5.6 Reprise
- 14.5.7 Engelchen und Teufelchen
- 14.5.8 Das Teufelchen mundtot machen
- 14.5.9 Komplikationen und Schlupflöcher
- 14.5.10 Kosten und Konsequenzen
- 14.6 Tests sauber halten
- 14.7 Tests ermöglichen die »-keiten«
- Kapitel 15: Saubere Tests
- 15.1 Domänenspezifische Testsprache
- 15.1.1 Zusammengesetzte Assertions
- 15.1.2 Zusammengesetzte Testergebnisse
- 15.1.3 Ein Doppelstandard
- 15.1.4 Single-Assert-Regel
- 15.1.5 Single-Act-Regel
- 15.2 F.I.R.S.T.
- 15.2.1 Fast (Schnell)
- 15.2.2 Isolated (Isoliert)
- 15.2.3 Repeatable (Wiederholbar)
- 15.2.4 Self-Validating (Selbstvalidierend)
- 15.2.5 Timely (Zeitnah)
- 15.3 Testdesign
- 15.4 Zusammenfassung
- Kapitel 16: Akzeptanztests
- 16.1 Die Akzeptanztest-Disziplin
- 16.1.1 Die Disziplin
- 16.1.2 Kontinuierlicher Build
- 16.2 Zusammenfassung
- Kapitel 17: KI, LLMs und wie sie alle heißen
- 17.1 Programmieren per Prompt
- 17.1.1 In den Kinderschuhen
- 17.1.2 Wilde wissenschaftliche Vermutung
- 17.2 Zusammenfassung
- Teil II: Design
- Kapitel 18: Einfaches Design
- 18.1 YAGNI
- 18.2 Abgedeckt durch Tests
- 18.2.1 Ein asymptotisches Ziel
- 18.2.2 Design?
- 18.3 Aussagekraft maximieren
- 18.3.1 Die zugrunde liegende Abstraktion
- 18.3.2 Tests: Die zweite Hälfte des Problems
- 18.4 Duplizierung minimieren
- 18.4.1 Zufällige Duplizierung
- 18.4.2 Größe minimieren
- 18.4.3 Einfaches Design
- Kapitel 19: Die SOLID-Prinzipien
- 19.1 SRP: Das Single-Responsibility-Prinzip
- 19.1.1 Zufällige Duplizierung
- 19.1.2 Lösungen
- 19.1.3 Höhere Ebenen
- 19.2 OCP: Das Open-Closed-Prinzip
- 19.2.1 Ein Gedankenexperiment
- 19.2.2 Richtungssteuerung
- 19.2.3 Information Hiding
- 19.2.4 Zusammenfassung
- 19.3 LSP: Das Liskov'sche Substitutionsprinzip
- 19.3.1 LSP und Softwaredesign
- 19.3.2 Taxi-Aggregator
- 19.4 ISP: Das Interface-Segregation-Prinzip
- 19.4.1 ISP und Programmiersprachen
- 19.4.2 ISP und Softwaredesign
- 19.5 DIP: Das Dependency-Inversion-Prinzip
- 19.5.1 Stabile Abstraktionen
- 19.5.2 Factorys
- 19.5.3 Konkrete Komponenten
- Kapitel 20: Komponentenprinzipien
- 20.1 Komponenten
- 20.2 Eine kurze Historie der Komponenten
- 20.2.1 Relokatierbarkeit
- 20.2.2 Linker
- 20.3 Komponentenkohäsion
- 20.3.1 Das Reuse/Release-Equivalence-Prinzip (REP)
- 20.3.2 Das Common-Closure-Prinzip (CCP)
- 20.3.3 Das Common-Reuse-Prinzip (CRP)
- 20.3.4 Das Spannungsdiagramm für die Komponentenkohäsion
- 20.3.5 Zusammenfassung
- 20.4 Komponentenkopplung
- 20.4.1 Das Acyclic-Dependencies-Prinzip (ADP)
- 20.4.2 Das Stable-Dependencies-Prinzip (SDP)
- 20.4.3 Das Stable-Abstractions-Prinzip (SAP)
- 20.5 Zusammenfassung
- Kapitel 21: Kontinuierliches Design
- 21.1 Kontinuierliche Veränderung
- 21.2 Kontinuierliches Design
- 21.3 Die vier K des kontinuierlichen Designs
- 21.3.1 Klarheit
- 21.3.2 Kürze
- 21.3.3 Konfirmierung
- 21.3.4 Kohäsion
- 21.4 Wann sind wir außerdem noch Designer?
- 21.4.1 Vorabdesign
- 21.4.2 Auf die Plätze!
- 21.4.3 Fertig!
- 21.4.4 Los!
- Kapitel 22: Nebenläufigkeit
- 22.1 Warum Nebenläufigkeit?
- 22.1.1 Mythen und falsche Vorstellungen
- 22.1.2 Herausforderungen
- 22.2 Prinzipien zur Absicherung von Nebenläufigkeit
- 22.2.1 Single-Responsibility-Prinzip
- 22.2.2 Korollar: Beschränken Sie den Gültigkeitsbereich von Daten
- 22.2.3 Korollar: Arbeiten Sie mit Kopien der Daten
- 22.2.4 Korollar: Threads sollten voneinander so unabhängig wie möglich sein
- 22.2.5 Lernen Sie Ihre Programmiersprache und Bibliothek kennen
- 22.2.6 Threadsichere Collections
- 22.3 Lernen Sie Ihre Ausführungsmodelle kennen
- 22.3.1 Erzeuger-Verbraucher
- 22.3.2 Leser-Schreiber
- 22.3.3 Philosophenproblem
- 22.4 Achten Sie auf Abhängigkeiten zwischen synchronisierten Methoden
- 22.5 Halten Sie synchronisierte Abschnitte klein
- 22.6 Korrekten Startup- und Shutdown-Code zu schreiben, ist schwer
- 22.7 Threaded-Code testen
- 22.7.1 Behandeln Sie gelegentlich auftretende Fehler als potenzielle Threading-Probleme
- 22.7.2 Bringen Sie erst den Nonthreaded-Code zum Laufen
- 22.7.3 Machen Sie Ihren Threaded-Code austauschbar
- 22.7.4 Schreiben Sie anpassbaren Threaded-Code
- 22.7.5 Den Code mit mehr Threads als Prozessoren ausführen
- 22.7.6 Den Code auf verschiedenen Plattformen ausführen
- 22.7.7 Code instrumentieren, um Fehler zu provozieren
- 22.8 Nachtrag im Jahr 2025: Neue Erkenntnisse aus der Praxis
- 22.8.1 Datenintegrität
- 22.9 Zusammenfassung
- Teil III: Architektur
- Kapitel 23: Die Geschichte zweier Werte
- 23.1 Optionen offenhalten
- Kapitel 24: Unabhängigkeit
- 24.1 Use Cases
- 24.2 Betrieb
- 24.3 Entwicklung
- 24.4 Deployment
- 24.5 Optionen offenhalten
- Kapitel 25: Architekturgrenzen
- 25.1 Welche Grenzen sollten Sie ziehen - und wann?
- 25.2 Plugin-Architektur
- 25.3 Fallstudie: FitNesse
- 25.4 Zusammenfassung
- Kapitel 26: Saubere Grenzen
- 26.1 IoT-Framework vom Drittanbieter: Jede Menge Grenzen
- 26.2 Grenze zwischen UI und Anwendung
- 26.2.1 SOLID und hexagonale Architektur
- 26.2.2 Grenzen erforschen und kennenlernen
- 26.2.3 Code verwenden, der noch nicht existiert
- 26.3 Saubere Grenzen
- Kapitel 27: Saubere Architektur
- 27.1 Die Abhängigkeitsregel
- 27.1.1 Entitäten
- 27.1.2 Use Cases
- 27.1.3 Schnittstellenadapter
- 27.1.4 Frameworks und Treiber
- 27.1.5 Nur vier Kreise?
- 27.1.6 Grenzen überschreiten
- 27.1.7 Welche Daten überschreiten die Grenzen?
- 27.2 Ein typisches Beispiel
- 27.3 Zusammenfassung
- Teil IV: Craftsmanship
- IV.1 »Eine große Anzahl«
- IV.2 Acht Jahrzehnte
- IV.2.1 Nerds und Helden
- IV.2.2 Berühmt und berüchtigt
- IV.2.3 Vorbilder und Schurken
- IV.2.4 Wir regieren die Welt
- IV.2.5 Katastrophen
- IV.3 Der Eid
- Kapitel 28: Schaden
- 28.1 Gesellschaftlicher Schaden
- 28.2 Funktionsbeeinträchtigungen
- 28.3 Schädigung der Struktur
- 28.4 Soft
- 28.5 Tests
- Kapitel 29: Weder im Verhalten noch in der Struktur fehlerhaft
- 29.1 Mach es richtig
- 29.1.1 Was ist gute Struktur?
- 29.1.2 Eisenhower-Matrix
- 29.2 Programmierer sind Stakeholder
- 29.3 Ihr Bestes geben
- Kapitel 30: Reproduzierbarer Beweis
- 30.1 Dijkstra
- 30.1.1 Beweis der Korrektheit
- 30.2 Strukturierte Programmierung
- 30.3 Funktionale Dekomposition
- 30.4 Test-Driven Development und mehr
- Kapitel 31: Kurze Zyklen
- 31.1 Die Geschichte der Versionsverwaltung
- 31.1.1 Lochkarten
- 31.1.2 Kontinuierliche Integration
- 31.1.3 Kurze Zyklen
- 31.2 Kontinuierliche Integration
- 31.3 Branches versus Toggles
- 31.4 Kontinuierliches Deployment
- 31.5 Kontinuierlicher Build
- Kapitel 32: Unablässliche Verbesserung
- 32.1 Testabdeckung
- 32.2 Mutationstests
- 32.3 Semantische Stabilität
- 32.4 Aufräumen
- 32.5 Kreationen
- Kapitel 33: Hohe Produktivität beibehalten
- 33.1 Viskosität
- 33.1.1 Build erstellen
- 33.1.2 Testen
- 33.1.3 Debugging
- 33.1.4 Deployment
- 33.2 Ablenkungen
- 33.2.1 Meetings
- 33.2.2 Musik
- 33.2.3 Stimmung
- 33.2.4 Der Flow
- 33.3 Zeitmanagement
- Kapitel 34: Teamarbeit
- 34.1 Kollaborative Programmierung
- 34.2 Offenes/virtuelles Büro
- Kapitel 35: Ehrliche und faire Schätzungen
- 35.1 Lügen
- 35.2 Ehrlichkeit, Genauigkeit, Präzision
- 35.3 Lehren aus meiner Praxis
- 35.3.1 Geschichte 1: Vektoren
- 35.3.2 Geschichte 2: pCCU
- 35.3.3 Die Lehre
- 35.4 Genauigkeit und Präzision
- 35.5 Aggregation
- 35.6 Ehrlichkeit
- 35.7 Druck
- Kapitel 36:Respekt gegenüber Mitprogrammierern
- Kapitel 37: Niemals aufhören zu lernen
- Nachwort
- Bibliografie
- Anhang: Die Clean-Code-Debatte
- A.1 Einführung
- A.2 Methodenlänge
- A.2.1 Zusammenfassung zur Methodenlänge
- A.3 Kommentare
- A.3.1 Zusammenfassung zu Kommentaren
- A.3.2 Johns Neufassung von PrimeGenerator
- A.3.3 Eine Geschichte von zwei Programmierern
- A.3.4 Bobs Neufassung von PrimeGenerator2
- A.4 Test-Driven Development
- A.4.1 TDD-Zusammenfassung
- A.5 Abschließende Bemerkungen
- Stichwortverzeichnis
System requirements
File format: ePUB
Copy protection: Watermark-DRM (Digital Rights Management)
System requirements:
- Computer (Windows; MacOS X; Linux): Use a reading software that can process the file format ePUB: e.g., Adobe Digital Editions or FBReader – both free (see eBook Help).
- Tablet/Smartphone (Android; iOS): Before downloading, install the free app Adobe Digital Editions (see eBook Help).
- E-reader: Bookeen, Kobo, Pocketbook, Sony, Tolino and many more (not Kindle).
The file format ePUB works well for novels and non-fiction books – i.e., „flowing” text without complex layout. On an e-reader or smartphone, line and page breaks automatically adjust to fit the small displays.
This eBook uses Watermark-DRM, a „soft” copy protection. This means that there are no technical restrictions to prevent illegal distribution. However, there is a personalised watermark embedded in the eBook that can be used to identify the purchaser of the eBook in the event of misuse and to provide evidence for legal purposes.
For more information, see our eBook Help page.