Clean Code

Du bist hier :

{{#youAreHere:Clean Code}}

Einleitung

Der Begriff Clean Code stammt vom gleichnamigen Buch von Robert C. Martin. Clean Code ermöglicht das Entwickeln intuitiver und wartbarer Systeme. Dabei wird die Softwareentwicklung als Handwerk (Craftmanship) verstanden. Clean Code ist unabhängig von der eingesetzten Programmiersprache.

Prinzipien

• Don't Repeat Yourself (DRY)
  • Keine Codeduplizierungen.
• Keep It Simple, Stupid (KISS)
  • Code so einfach wie möglich halten.
• Favour Composition Over Inheritance (FCoI)
  • Durch Vererbung wird Code komplexer.
  • Code wird durch Komposition flexibler.
  • Klassen können unabhängig voneinander getrennt entwickelt und getestet werden.
• One Level of Abstraction
• Single Responsibility Principle (SRP)
  • Jede Klasse bzw. Methode nur für eine Aufgabe zuständig.
• Interface Segregation Principle
  • Schnittstellen möglichst genau auf Klienten zuschneiden.
• Open Closed Principle (OCP)
  • Softwareeinheit sollte offen für Erweiterungen und geschlossen für Änderungen sein.
  • Änderungen durch Hinzufügen von neuem Code vornehmen und nicht durch Anpassen des Bestehenden.
• Test First
  • Test vor Implementierung erstellen.
  • Test Driven Development (TDD) ist Entwicklersache und unabhängig von der Qualitätssicherung.

Empfehlungen

Viele der hier genannten lassen sich insbesondere in objektorientierten Sprachen einsetzen. Einige Empfehlungen sind speziell für Java.

Attribute

• Aussagekräftige Namen verwenden: int elapsedTimeInDays; statt int d;
• Aussprechbare Namen benutzen.
• Ein Wort durchgängig für ein Konzept benutzten, z.B. remove, um ein Element aus einem Container zu entfernen.

Methoden

• Kurze Methoden schreiben.
• Methode erfüllt genau einen Zweck.
• Aussagekräftigen Methodennamen verwenden.
• Anweisungen in try-catch-Blöcken in eigene Methoden auslagern.
• Möglichst wenige Parameter verwenden.

Kommentare

• Statt Kommentaren aussagekräftige Bezeichner verwenden.
• Am Beginn einer Klasse auf Versionshistorie verzichten.
• In Klassen nicht die Lizenz angeben sondern nur Verweis auf diese.
• Private Methoden und Attribute nicht mit JavaDoc oder Doxygen-Kommentaren versehen.
• Statt Code auszukommentieren diesen löschen.

Formatierungen

• Klassen klein halten (ca. 500 Zeilen)
• Instanzvariablen am Klassenanfang definieren
• Zeilenlänge bis maximal 120 Zeichen
• Aufrufende Methode soll vor aufgerufener Methode in unmittelbarer Nähe stehen, wenn die Programmiersprache dies zulässt.

Fehlerbehandlung

Statt Fehlercode zurückgeben, eine Exception werfen.

• In Java sind Unchecked Exceptions Checked Exceptions vorzuziehen.
• Methoden sollten nicht null zurückgeben.
• Methoden sollte als Parameter nicht null übergeben werden.

Randbedingungen

• Beim Einsatz von 3rd-Party-Bibliotheken diese anhand von Unit-Tests evaluieren.
• Eventuell 3rd-Party-Bibliotheken wrappen, um diese wieder leicht austauschen zu können.

Unit Tests

• Tests vor dem Produktcode erstellen.
• Eine Assert-Methode pro Testroutine.
• Pro Test nur ein Konzept testen.
• Testcode ist genauso wichtig wie der Produktcode.

Weiterführende Informationen

1. Clean Code - A Handbook of Agile Software Craftsmanship, Robert C. Martin, Prentice Hall, 2009
2. Clean Code Developer http://clean-code-developer.de/

---