Cleancode Prinzipien

Es machen viele Dinge Cleancode aus. Eine der wichtigsten sind die Cleancode Prinzipien. Diese beziehen sich nicht auf eine bestimmte Programmiersprache. Gerade beim heutigen Webdevelopment merkt man auch immer häufiger das gerade Javascript immer komplexer und anspruchsvoller wird.

Cleancode Prinzipien

Nachfolgend sind 15 Prinzipien aufgeführt. Das sind nicht alle und auch nicht die wichtigsten. Aber sehr bekannte, die man als Cleancoder nicht nur gehört, sondern auch Anwenden muß.

Seinen Quellcode nicht wiederholen. Eine häufige Fehlerquelle ist hier natürlich Copy / Paste. Aber in der Praxis stellt sich leider auch immer wieder heraus, das sehr ähnliche Logik in unterschiedlichen Klassen und Methoden verwendet wird. Fachlich sagt man in dem Zusammenhang gerne, daß Inkonsistenzen Vorschub geleistet wird. Unabhängig vom DRY-Prinzip ist Copy / Paste immer ein Problem bei der Programmierung. Hier ist es als Phpstorm User besser mit Live templates zu arbeiten.
Wikipedia DRY Dont’t repeat yourself (DRY)

Keep it simple, stupid (KISS)

Das ist eines der wichtigsten Prinzipien. Aber das ganze ist sehr schwer zu verwirklichen. Gerade wenn man viel alleine programmiert fehlen einem neue Eindrücke und andere Blickwinkel. Hier ist Pair-Programming wichtig. Grundsätzlich geht es darum große Probleme in Teilprojekte oder Teilprobleme zu zerlegen und so die Komplexibilität auszulagern und besser erfassbar zu machen. Der einfache und schnelle Weg soll bevorzugt werden. Die Axt im Wald ist dabei nicht immer die Antwort.
Keep it simple [and]stupid

Beware of Optimizations

Wenn Optimierungen nicht nötig sind bedeuten sie Aufwand bieten natürlich auch Fehlerpotential. So zumindest die Theorie zu dem Cleancode Prinzip. Aber in der heutigen Zeit muß Code gewartet und optimiert werden. Als ständiger Prozess ist das nötig, damit man nicht Code von vor über 5 Jahren mit schleppt den keiner mehr kennt und der eine echte Blackbox wird. Aber natürlich ist Code schon kaputt optimiert werden.

Favour Composition over Inheritance (FCoI)

Vererbungen sind nicht immer nötig und auch nicht so flexibel, wie eine Komposition. Daher sollte man genau schauen, ob nicht eine Komposition möglich ist.
Komposition an Stelle von Vererbung

Single Responsibility Principle (SRP)

Eine Klasse für eine Aufgabe. Deshalb sollen Klassen auch nicht viele Methoden haben. Das wird in der Praxis leider sehr häufig missachtet. Ich habe Controller gesehen und auch geschrieben, die Logik ganzer Applikationen beinhalten. Das ist bei den heutigen IDE und gerade bei PhpStorm nicht mehr nötig. Das Symfony Php-Framework bietet hier mit den Services eine tolle Möglichkeit Logik auszulagern und für andere Klassen verfügbar zu machen.
Single Responsibility Principle (SRP)

Dependency Inversion Principle (DIP)

Module sollten über Interfaces entkoppelt werden. Dabei kann man 2 Regeln besondere Beachtung schenken.

• Ein Module auf einer hohen Ebene sollte nicht von Modulen niedriger Ebenen abhängen. Beide sollten allerdings von Abstraktionen abhängen.
• Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen.

Dependency-Inversion-Prinzip

Liskov Substitution Principle (LSP)

Subtypen müssen sich wie ihr Basistyp verhalten. Beispielsweise darf eine Methode, die im Basistyp keine Exception wirft, auch im Subtyp keine Exception werfen. Ein Subtyp darf die Funktionalität eines Basistyps nur erweitern, aber nicht einschänken.
Liskovsches Substitutionsprinzip (LSP)

Information Hiding Principle

Eine Klasse sollte nur die für die API notwendigen Methoden und Attribute öffentlich zur Verfügung stellen. Durch das Verbergen der Implementierungsdetails wird die Benutzung der Klasse von ihrer Implementierung unabhängig gemacht. Leider ist sehr häufig zu beobachten, daß alle in Klassen auf public gesetzt wird. Das liegt häufig an der Voreinstellung in einer IDE wie Phpstorm. Andere nutzen das, damit ihre Phpunit Tests besser zu schreiben sind. Beides ist falsch. Wenn man denn doch alle Methoden testen möchte kann man auch mit Unittests auf protected und private Methoden und Attribute zugreifen. Aber gerade in den Zeiten einer IDE ist klar das einem die Autovervollständigung alles was public ist anbietet. Und damit können sich Methoden aufrufe im Quellcode verschleppen, die man später nicht ohne weiteres refaktorisiert bekommt. Daher soll man bei public immer doppelt nachdenken, ob es nötig ist und der Name so gut wie möglich ist. Interne Methoden kann man ja nach belieben neu benennen. Bei public Methoden kann das schwierig bis unmöglich werden.
Information hiding

Principle of Least Astonishment

Methoden sollten das tun was man erwartet. Der Name soll die Funktion beschreiben. Und es soll nur eine Funktion sein. Das geht in der Praxis leider nicht immer auf. Komplexere Programmteile können dann ein einer Handler-Methode passieren. Ein Beispiel. die Methode getContent($path). Hier kann man sich vorstellen das der Inhalt zu einem bestimmten Pfad geholt wird. Sinnvoller wäre hier der Name getContentByPath($path). Hier weiß man streng genommen noch nicht, was man zurück bekommt. Fertiges HTML? Und wo kommt der Content denn her. Aus einem Redis Cache? Wann und wie wird der geschrieben. Das sind wichtige Fragen für die Implementierung, aber nicht für die Anwendung. Und das kann alles in der Methode stehen, ohne das man sie contentHandler nennt. Man erwartet Content zu einem Pfad. das ist aussagekräftig. Kann aber noch besser werden. Das soll hier aber nicht zum langen Thema werden.
Principle of Least Surprise

Tell, don’t ask

Eine Klasse sollte nicht ihren internen Zustand nach aussen geben. Es ist besser dem Objekt mitzuteilen was es zu tun hat. Das bringt die Logik zur Benutzung der Klasse in die eigentliche Klasse und man muss sich ausserhalb darüber keine Gedanken mehr machen. Als Ergebnis entstehen Objekte mit einem Verhalten und keine Datenhaltungsobjekte.
Martin Fowler Tell don’t ask

Law of Demeter

Eine Verkettung von Abhängigkeiten führt zu einer engel Kopplung des Projekts. Das ist alles andere als flexibel. Die gesamte Entwicklung wird länger und beschwerlich. Das macht die Arbeit sehr kostenintensiv. Auch verlieren die Mitarbeiter die Motivation. Das kann am Ende die ganze Abteilung oder gar die Firma ruinieren. Deshalb gibt es auch hier einige Regeln, die bei der Verwendung von Methoden innerhalb von Methoden beachtet werden sollte.

• Methoden der Klasse selbst
• Methoden der Parameter
• Methoden assozierter Klassen
• Methoden selbst erzeugter Objekte

Law of Demeter