Skip to main content
Entwickler Themen
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

4. Clean Code Übersicht

Was ist Clean Code?

Zwei Zitate umreißen das Ziel besser als eine Definition:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

— Martin Fowler

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

— Grady Booch

Warum Clean Code?

  • Lesbarkeit: Anderen (und dem späteren Ich) fällt das Verstehen leichter.
  • Wartbarkeit: Änderungen kosten weniger Zeit und erzeugen weniger Folgeschäden.
  • Fehlerbehebung: Klare Struktur macht Abweichungen sichtbar.
  • Zusammenarbeit: Gemeinsamer Code lässt sich erweitern, ohne ihn erst entschlüsseln zu müssen.
  • Skalierbarkeit: Neue Anforderungen lassen sich an bestehenden Nähten ansetzen.

Code Smells

Anzeichen, dass eine Überarbeitung lohnt:

  • Duplizierter Code: Dieselbe Logik an mehreren Stellen – Änderungen werden inkonsistent.
  • Überlange Methoden: Zu viele Schritte in einer Einheit; aufteilen.
  • Überlange Klassen: Zu viele Verantwortungen; in kleinere Typen schneiden.
  • Magic Numbers / Magic Strings: Unbenannte Literale statt benannter Konstanten oder Enums.
  • God Objects: Eine Klasse kennt und steuert alles.
  • Enge Abhängigkeiten: Viele konkrete Kopplungen statt klarer Schnittstellen.

SOLID

Fünf Prinzipien objektorientierter Struktur. Je ein Satz Beispiel:

  • Single Responsibility (SRP): Eine Klasse hat einen Grund zur Änderung – z. B. InvoiceCalculator rechnet, InvoicePdfWriter schreibt PDFs.
  • Open/Closed (OCP): Verhalten erweitern, ohne bestehenden Code umzubauen – neue Zahlungsart als weitere Implementierung, nicht als weiteres if in einer Riesenschalter-Methode.
  • Liskov Substitution (LSP): Eine Unterklasse darf überall stehen, wo der Basistyp erwartet wird, ohne Überraschungen.
  • Interface Segregation (ISP): Kleine, passende Interfaces statt eines „alles können“-Interfaces, von dem die Hälfte ungenutzt bleibt.
  • Dependency Inversion (DIP): Abhängigkeiten zeigen auf Abstraktionen (PaymentGateway), nicht auf eine konkrete StripeClient-Klasse.

Weiterführende Quellen

Clean Code Developer (extern)