Clean Code Robert C. Martin
Die bekannteste Lektüre zum Thema Clean Code ist aus dem Jahre 2008 von Robert Cecil Martin. Der bekannte Programmierer mit dem Alias „Uncle Bob“ war in den 70er und 80er Jahren ein echter Dotcom Star und hat sicherlich in der Hall of Fame einen eigenen kleinen Altar. In dem Buch wendet er sich ausschließlich an das Thema Clean Code. Allerdings ist nicht jeder Nerd auch ein guter Autor. Daher fange ich hier mal mit dem Thema Pflichtlektüre an.
Clean Code Robert Cecil Martin
Das Thema Clean Code teilt sich in mehrere Einzelbereiche. Code Standard, Code Struktur und Testabdeckung sollen hier jetzt einmal näher betrachtet werden. Grundsätzlich muß ich an dieser Stelle einmal darauf hinweisen das es ein tolles und motivierendes Thema ist. Betrachten wir jetzt einmal die einzelnen o.g. Punkte.
Clean Code Code Standards
Ich komme aus der Welt der PHP Programmierung und meine persönlichen intensiven Erfahrungen zum dem Thema haben dort ihre Wurzeln. Man kommt natürlich schell zum Pear PHP_Codesniffer. Das ist auch ein hervorragendes Tool. Code Standards sind nötig, wenn man im Team und auch alleine arbeitet. Dadurch wird die Lesbarkeit schon deutlich erhöht und die Struktur ist einheitlich. Code Standards zeichnen sich durch einzelne Code Sniffs aus. Neben dem Aufspüren von falsch gesetzten Klammern, Kommas und Zeilenlängen gibt es noch eine ganze Reihe weiterer interessanter Code Sniffs, die Beispielsweise ungeschützten Zugriff auf Superglobale Variablen finden, erkennen ob ein String wirklich doppelte Anführungszeichen benötigt oder ob eine String Concatenation an der Stelle wirklich gebraucht wird. Dazu lassen sich auch alle Sniffs über eine XML Datei konfigurieren. Also ausschließen oder verifizieren.
Code Struktur für Clean Code
Laut Robert C. Martin verbringt ein Programmierer über 90% seiner Zeit mit dem Lesen und der Analyse von Code. Damit man effektiver wird ist es also absolut entscheidend lesbaren Code zu schreiben. Das findet allerdings kein Code Sniffer raus. Hier hat Martin einige sehr interessante Ansichten in seinem Buch.
Keine Kommentare in Clean Code
Robert C. Martin ist gegen Kommentare. Das begründet er mit 2 sehr starken Argumenten. Er sagt, wenn ein Code kommentiert werden muß, ist er nicht lesbar genug. Aussagekräftige Namen für Klassen, Methoden und Variablen sind für ihn absolut entscheidend. Das zweite ebenfalls sehr schwergewichtige Argument ist, daß Kommentare nicht gewartet werden und dadurch schneller Legacy Code werden. Auch das ist richtig. Mehr Code macht mehr Arbeit. Kommentare sind Teil von Code. Die Arbeit, die man in Erklärungen steckt sollte man lieber in lesbaren Clean Code setzen. Auskommentiertes gehört auch immer aus Quellcode raus. Ideen, Todoes, Vorbereitungen für kommende Tasks. All so etwas ist auf der einen Seite hilfreich, allerdings auch sehr starkes Legacy Code Potential.
Lesbarer Code
Namen gerade bei Methoden sind echte Kunst. Der Name soll also das gesamte Tun einer Methode beschreiben. Zudem soll eine Methode auch nur eine Aufgabe haben. Beachtet man beide Regeln gibt es auch keine Probleme. Ein einfaches Beispiel soll mal eine Methode getContent($path){…} sein. Hier kann man sich zwar vorstellen, was passiert und doch bleiben viele Fragen offen. Was genau ist der Pfad? Eine URL oder eine Pfad zu einer Content Datei? Was ist denn der Content? Physikalische Files? Ein Datenbankeintrag? Kommen die Daten aus einem Cache und wird dieser ggf. generiert? Das sind alles Fragen, die mit einem Methoden Namen nicht beantwortet werden können. Daher eine Methode – eine Aufgabe. Das macht Code natürlich auch besser testbar. Martin sagt z.B. für Variablen Namen soll keine Typisierung genutzt werden und auch keine Füllwörter, wie Info oder Data. Eine Variable userData bringt Robert C. Martin schon richtig in Rage. Was sollen das für Daten sein? Adresse? Bestell Historie? Liefer- und Empfänger Adressen? Das auf den Punkt zu bringen ist echte Handwerkskunst. Die Zeit, die man mit der Optimierung verbringt bekommt man später locker wieder rein.
Clean Code – Testabdeckung
Eine hohe Testabdeckung ist das wichtigste Kriterium für gute Softwarequalität. Tests sind wichtig und sparen sehr viel zeit und Geld. Nur wer Tests schreibt, steht seinem eigenen Code auch kritisch gegenüber. Was passiert, wenn ein Parameter leer oder von falschen Typ ist. Wie viele Abhängigkeiten sind hier, kann man den Code nicht verbessern?
Das grauenhafte an Clean Code von Robert C. Martin Uncle Bob
2 wesentliche Teile in dem Buch machen die Lektüre sehr zäh. Robert C. Martin und sein Code. Bei Robert ist seine nerdige Art und seine permanente Selbstbeweihräucherung von sich und seinem Code echt zum kotzen. Ich habe das Buch in meinem Flitterwochen auf Sri Lanka abends auf dem Balkon auf einem Kindle gelesen. Das mag nichts ungewöhnliches sein. Für Martin schon. Der weißt das gesamte erste Kapitel darauf hin, daß man diese seine heiligen Worte – er taucht da in eine echte spooky Parallelwelt ab – nur in absoluter Ruhe und Konzentration in einem abgedunkelten Raum mit tollen Rechner und Monitor verbringen muß. Alles andere wäre Sünde. Nun ich habe mich trotzdem weiter durchgelesen. Und auch wenn er fachlicher wurde hatte es immer diesen Nerd Beigeschmack. Aber gut er ist ja auch einer. Das andere ist der Code. Es ist JAVA ok das ist noch ok. Aber dann auch noch sehr alter Code. Nicht vergleichbar mit der heutigen PHP Welt oder gar modernen Frameworks. Das wäre ja alles nicht schlimm. Aber die Refaktorisierungen sind nicht gerade Innovationsgranaten. Aber er badet in seiner Selbstverliebtheit, daß man das auch nur bei schöner Abendsonne mit ein paar Bier übersteht.
Fazit zu Martin C. Robert Clean Code
Grauenhafte Pflichtlektüre. Habe ich schon gesagt, kann ich aber immer wieder nur wiederholen. Die Prinzipien, die ich oben kurz angerissen habe machen den Kern des Buches aus und sind die wesentliche Message. Ich wäre zu dem Zeitpunkt schwer enttäuscht hätte das Buch dann nicht doch noch eine starke Sache gehabt hätte. Die Clean Code Regeln. Die sind gut und werden in kommenden Artikel hier veröffentlich und kommentiert. Also kann man sagen es lohnt sich dieses Buch zu lesen. Es motiviert und macht einen sensibel für schlechten Code. Es macht viel Spaß seinen Code kritisch zu betrachten und es brigt einen schnell weiter und verbessert die persönlichen Skills.
Kindle Clean Code bei Amazon
http://www.amazon.de/gp/product/B00HCMATO6/ref=oh_d__o03_details_o03__i00?ie=UTF8&psc=1
