Die wichtigsten Clean-Code Regeln

YAGNI – You ain‘t gonna need it

Es sollte nichts implementiert werden, was vielleicht in der Zukunft verwendet werden kann, denn es ist sehr wahrscheinlich, dass es nicht benötigt wird und es würde sonst nur den Code größer und komplexer machen und somit schwieriger zu verstehen und schwerer zu warten.

KISS – Keep it Simple Stupid

Halte den Source-Code möglichst einfach und simple. Wenn es einen einfachen Weg gibt etwas zu implementieren sollte dieser Weg begangen werden. Zusätzliche Komplexität macht den Code schwieriger zu verstehen und somit schwer wartbar.

 

DRY – Don’t repeat yourself

Jede Verdopplung von Source-Code oder Information in einer Software ist schlecht, denn dies kann zu potenziellen Inkonsistenzen führen und macht es schwierig die Software zu warten.

Principle of least astonishment surprise

Eine Komponente eines Systems muss sich immer so verhalten wie es die meisten Menschen erwarten würden. Das Verhalten sollte nie den Aufrufer erstaunen oder überraschen, sondern logisch sein und sich „richtig anfühlen“

Seperation of Conserns

Eine Software oder ein Software-System soll in verschiedene eindeutige Abschnitte zerteilt werden, wobei jeder Abschnitt seine eigenen spezifischen Aspekte abbildet.

 

Law of Demeter

Das Law of Demeter wird auch Prinzip des geringsten Wissens genannt. Jede Einheit in einem Software-System soll so wenig Wissen wie möglich und so viel wie nötig enthalten. Jede Einheit sollte auch nur mit seinen “Freunden” sprechen und nicht mit „Fremden“. Das heißt es sollen nur Methoden von Objekten aufgerufen werden die als Argumente übergeben wurden, lokal erzeugt wurden, global verfügbar sind oder bei der Instanziierung übergeben wurden.

Beispiel: Ein Aufruf HundàBein 1 bis 4 à gehen() ist nicht ok. Hundà gehen() ist ok. Hund à Schwanz à Wedeln() ist auch ok.

Encapsulation

Encapsulation oder Kapselung ist ein Mechanismus zum Einschränken des Zugriffs auf Objekte oder Komponenten. Der Zugriff auf interne Daten eines Objekts von außen ist nur durch definierte Interfaces erlaubt, wie zum Beispiel public Methoden.

Single Level of Abstraction

Alle Statements und Befehle einer Methode sollten zum selben Abstraktionslevel gehören. Wenn einige Befehle zu einen niedrigeren Abstraktionslevel gehören, sollten sie in eine private Methode ausgelagert werden, die diese niedrigeren Abstraktionslevel-Befehle zusammenfasst. Dies Reduziert dann die mentale Last, die der Leser benötigt, um den Code zu verstehen. Menschen können immer nur eine Hand voll an Informationen halten und sind somit auf dies Vereinfachung angewiesen.

Inversion of Control

Inversion of Control oder Dependency-Injection ist die Anwendung des Hollywood-Prinzips. „Rufen Sie nicht an wir rufen Sie an.“ Normalerweise sind in der objektorientierten Welt Objekte und Komponenten fest miteinander verkoppelt. Der Programmfluss wird bestimmt von den Objekten, die aneinander gebunden sind. Bei Inversion of Control Erzeugen sich die Objekte ihre Abhängigkeiten nicht selbst sondern bekommen die Objekte von einen Containermanager von außen geliefert. Dies führt zu einer losen Kopplung.

Unittests

Unittests sind ein maßgeblicher Teil von Clean-Code. Sie bilden die Funktionalität der Software in Form von abgekapselten elementaren automatisierten Tests ab. Unittests sollen immer unabhängig voneinander sein und möglichst Elementare Funktionalitäten abtesten.

 

Single Point of Truth

Jede Art von Wissen in einem Software-System soll eine eindeutige unmissverständliche und autoritär verbindliche Stelle sein, die nur einmal im System vorkommt. Dabei geht es nicht nur um Source-Code sondern auch um Informationen, Datenbanken, Daten, Tests, Tools und Buildsysteme bzw. Buildartefakte, sowie Dokumentationen.

SOLID

Single Responsibility Principle

Jede Einheit, jedes Modul eines Software-Systems soll nur eine einzige Verantwortung/Aufgabe haben die es erfüllt. Es soll auch immer nur einen Grund geben ein Modul zu ändern.

Open-Close Principle

Komponenten sollen offen sein für Änderungen und Erweiterungen aber geschlossen für Modifikation von außen.

Liskov-Substitution Principle

Objekte in einem Software-System sollten durch ihre Sub-Typen und Ableitungen jederzeit ersetzt werden können ohne das sich etwas an der Korrekten Ausführung des Systems ändert.

Ein Beispiel:

Wenn man ein Gefäß zum Ausschaufeln eines vollgelaufenen Bootes verwenden kann, sollte man auch eine Tasse zum Ausschaufeln eines vollgelaufenen Bootes verwenden können, weil die Tasse ebenfalls ein Gefäß ist. Sonst geht man mit dem Boot unter.

Interface seregation Principle

Ein Developer sollte nie gezwungen sein in einem Interface nicht für ihn benötigte Methoden aus zu programmieren. Wenn dem so ist wäre es sinnvolle das Interface in mehrere Interfaces zu trennen.

Beispiel:

Ein Interface Schweizer Taschenmesser ist schlecht es sollte in viele Interface für Messer, Schere, Säge, Feile, … aufgeteilt werden

Dependency Inversion Principle

Ein Element sollte immer von Abstraktionen abhängig sein, nicht von abgeleiteten konkreten Klassen. Das heißt Highlevel-Module sollten nur von Abstraktionen abhängig sein nicht von Lowlevel-Modulen.