Clean Code ist ein Begriff aus der Softwaretechnik, der durch das gleichnamige Buch von Robert Cecil Martin populär wurde. Als „sauber“ (clean) bezeichnen Softwareentwickler in erster Linie Quellcode, aber auch Dokumente, Konzepte, Regeln und Verfahren, die intuitiv verständlich programmiert bzw. konzipiert sind. Vorteile von Clean Code sind stabilere und effizient wartbare Programme, was in einer kürzeren Entwicklungszeit bei Funktionserweiterungen und Fehlerbehebungen resultiert. Vor dem Gesichtspunkt, dass im Schnitt 70–80 % der Lebensdauer einer Software in den Wartungszeitraum fällt[1][2], erhält die Einhaltung von Clean Code-Prinzipien zur Verbesserung der Leserlichkeit und Verständlichkeit besondere Relevanz.

Schwierigkeiten beim Entwickeln von Clean Code liegen

  1. häufig in zunächst unklaren oder sich widersprechenden Anforderungen,
  2. zum Teil begründet im Fehlen von Erfahrung im Entwickeln von Clean Code,
  3. im Mangel an Disziplin beim Programmieren und
  4. im Aufwand nachträglicher Quellcode-Bereinigungen (dem sog. Refactoring).

Die Notwendigkeit, Code noch nach der Entwicklung von „unsauberen“ Stellen zu reinigen, wird häufig nicht gesehen oder vom Management nicht bewilligt, sobald das Programm seine vorgesehene Funktion ausübt. Ein direktes Schreiben von „sauberem“ Code ist nahezu unmöglich, kann jedoch durch den bewussten Umgang mit den Prinzipien und Praktiken von Clean Code verbessert werden.

Eng verbunden mit dem Begriff Clean Code sind Maßnahmen, die bei der Entwicklung von Software zu „sauberem“ Programmcode führen. So zahlreich wie die Gründe für „unsauberen“ Code sind, so vielfältig sind auch die vorgeschlagenen Regeln in den aufgestellten Maßnahmenkatalogen. Dazu gehören:

Darüber hinaus gibt es seit einigen Jahren eine Clean-Code-Developer-Bewegung, die das Ziel verfolgt, ein einheitliches und umfassendes Regelwerk auf eine didaktisch ansprechende Weise in das Bewusstsein der Entwickler zu rücken und damit die Disziplin zu fördern, die Clean-Code-Maßnahmen im Programmieralltag auch tatsächlich anzuwenden. Als Maßnahme, diese Vorgehensweise zu üben, werden Katas vorgesehen.

Weitere Maßnahmen

Bearbeiten
  • Don’t repeat yourself (wiederhole dich nicht) – Wenn Code nicht mehrfach geschrieben wird, erhöht sich die Wartbarkeit, da nur an einer Stelle eine Änderung umgesetzt werden muss. Es können also keine Fehler entstehen, dadurch dass vergessen wird Quelltextklone ebenfalls anzupassen, weil es diese nicht gibt.
  • Konvention vor Konfiguration
  • Principle of Least Surprise (Prinzip der geringsten Überraschung) – Ein Prinzip, dass sowohl auf die Gestaltung der UI als auch auf den Code selbst, z. B. Benennung von Variablen angewendet werden kann.
  • YAGNI (You Ain’t Gonna Need It) – Wird beim Schreiben vom Code an etwaige zukünftige Features gedacht und der Code unnötig komplexer entworfen, kann er dadurch schlechter wartbar werden.

Entwurfsmuster für Klassen

Bearbeiten

Siehe auch

Bearbeiten

Literatur

Bearbeiten
  • Kent Beck: Clean code: Pipe dream or state of mind? In: Smalltalk Report. Band 4, Nr. 8, Juni 1995, S. 20–22 ([1] [PDF; abgerufen am 2. Februar 2025]).
  • Robert C. Martin: Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code. mitp-Verlag, 2008, ISBN 978-0-13-235088-4.
  • Andreas Wintersteiger: Clean Code. In: Der Entwickler. 12. Juni 2012 ([2] [abgerufen am 16. März 2018]).
  • Hendrik Lösch: Clean Code vs. Abhängigkeiten. In: Informatik Aktuell. 20. Juni 2017 ([3] [abgerufen am 16. März 2018]).
  • Juliane Conte: Clean Code Developer aus Unternehmenssicht. In: Heise Developer. 5. Dezember 2011 ([4] [abgerufen am 16. März 2018]).
Bearbeiten

Einzelnachweise

Bearbeiten
  1. Meir M. Lehman: Programs, Life Cycles, and Laws of Software Evolution. In: Institute of Electrical and Electronics Engineers (Hrsg.): PROCEEDINGS OF THE IEEE. Vol. 68, No. 9, September 1980, S. 1060.
  2. D.J. Robson, K.H. Bennett et al.: Approaches to program comprehension. In: Elsevier (Hrsg.): Journal of Systems and Software. Volume 14, Issue 2, Februar 1991, ISSN 0164-1212, S. 79–84.

📚 Artikel Terkait di Wikipedia

Assemblersprache

Hall, Upper Saddle River NJ 2003, ISBN 0-13-142044-5. Steve McConnell: Code Complete. A practical Handbook of Software Construction. Microsoft Press, Redmond

Lines of Code

Lines of Code (kurz LOC; englisch für Code-Zeilen i. S. v. Anzahl der Programmzeilen; engl. source lines of code, SLOC) ist ein Begriff aus der Softwaretechnik

Review (Softwaretest)

restlichen Code zu integrieren. Darüber hinaus ist es auch möglich Problemstellen, die durch Werkzeuge für statische Codeanalyse im zu reviewenden Code erkannt

Millersche Zahl

Fachmedien Wiesbaden. 2019, abgerufen am 22. Oktober 2019.  Steve McConnell: Code Complete. A Practical Handbook of Software Construction. 2. Auflage. Microsoft

Claude

Claude Code in Kombination mit Opus 4.5 weithin als der beste KI-Coding-Assistent, wobei auch GPT-5.2 deutliche Verbesserungen zeigte. Claude Code wurde

Testgetriebene Entwicklung

Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Code-Duplizierung), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen

Programmfehler

Fehlerdichte. Sie bezeichnet die Anzahl an Fehlern pro 1.000 Zeilen Code (Kilo Source Lines of Code) bzw. je Function Point. Als spezielle Instrumente zur Suche

Modultest

Auflage. dpunkt, Heidelberg 2002, ISBN 3-89864-156-2.  Steve McConnell: Code Complete. 2. Auflage. Microsoft Press, Redmond 2004, ISBN 978-0-7356-1967-8,