Clean Code Software-Entwicklung als Handwerkskunst Thomas Nagel, November 2011

Clean Code – warum? Code wächst und wächst Der Kostendruck steigt Für Erweiterungen muß Code pflegbar sein Schlechter Code ist nicht pflegbar Schlechter Code ist daher unwirtschaftlich Schlechter Code kann zum Untergang von Teams, Abteilungen, ganzen Firmen führen

Bjarne Stroustrup, Erfinder von C++ und Autor von Die C++ Programmier- sprache: I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an acticulated strategy, and performance close to to optional so as not to tempt people to make code messy with unprincipled optimizations. Clean code does one thing well. Clean Code – was ist das

Grady Booch, Autor von Objekt-orientierte Analyse Clean code is simple and direct. Clean code reads like well-written pproce. Clean code never obscures the designers intent but rather is full of crisp abstractions and straightforward lines of control. Clean Code – was ist das

Dave Thomas, Gründer der Eclipse-Strategy Clean code can be read, and enhanced b a developer other than ist original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. Clean Code – was ist das

Ward Cunningham, Erfinder des Wiki, Mit-Erfinder von XP, Design Patterns, SmallTalk … You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem. Clean Code – was ist das

Bedeutungsvolle Namen Namen sollen vor allem aussagekräftig sein Vermeiden Sie Falschinformationen Namen dürfen heute länger sein! Scope-Regeln: länger/kürzer Benutzen Sie die richtige Wortart: – Nomen für Klassen, Objekte, Variablen – Verben für Funktionen und Methoden – Adjektive für Eigenschafts-Methoden

Funktionen Sollten kurz sein Sollten noch kürzer sein Sollten nur eine Aufgabe erfüllen Sollten nur eine Abstraktionsebene benutzen Je weniger Argumente je besser Boolean-Argumente vermeiden Ergebnisse sollten im Objekt abgelegt werden Bei Fehlern Exceptions auslösen!

Kommentare Sind kein Ersatz für Code Häufig überflüssig Meistens nicht gepflegt Können den Bezug zum Code verlieren Javadoc ist fast nur Tautologie Überflüssige stören die Lesbarkeit Auskommentiertes löschen!

Klassen und Objekte

Fehlerbehandlung

Unit Tests und TDD

Vielen Dank für die Aufmerksamkeit! Links: