Clean Code: Sauberer Programmcode im Check

Clean Code geht auf Robert Cecil Martin zurück, der ihn in seinem Buch „Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code“ als Begriff für sauber geschriebenen Code geprägt hat. Die Clean-Code-Prinzipien sind allerdings wesentlich älter und haben ihren Ursprung eigentlich gar nicht in der Software-Entwicklung. Wir erklären, was sauberen Code ausmacht, worin die Vorteile bestehen und wie Sie selbst sauberen Code schreiben können.

Was ist Clean Code?

Clean Code ist kein strenges Regelwerk, sondern bezeichnet eine Reihe von Prinzipien, um Code zu produzieren, der intuitiv verständlich und leicht zu ändern ist. Verständlich bedeutet in diesem Fall, dass der Code von jedem geschulten Entwickler auf Anhieb erfassbar ist. Folgende Eigenschaften erleichtern die einfache Lesbarkeit von Clean Code:

  • Der Ausführungsablauf der gesamten Anwendung ist sinnvoll und einfach strukturiert.
  • Der Zusammenhang verschiedener Teile des Codes ist klar ersichtlich.
  • Die Aufgabe bzw. Rolle jeder Klasse, Funktion, Methode und Variable ist auf Anhieb verständlich.

Leicht zu ändern ist Code dann, wenn er einfach anpassbar und erweiterbar ist. Dies macht es wiederum leichter, Fehler im Code zu beheben. Clean Code ist daher sehr wartungsfreundlich. Leicht zu verändernder Code hat folgende Merkmale:

  • Klassen und Methoden sind klein und haben möglichst nur eine einzige, eindeutige Aufgabe.
  • Klassen und Methoden sind vorhersehbar, funktionieren erwartungsgemäß und sind durch gut dokumentierte APIs (Schnittstellen) öffentlich zugänglich.
  • Der Code verfügt über Unit-Tests.

Die Vorteile einer solchen Programmierung liegen auf der Hand: Clean Code ist unabhängig vom ursprünglichen Entwickler. So kann prinzipiell jeder Programmierer mit dem Code arbeiten. Probleme, die beispielsweise bei der Arbeit mit Legacy Code auftreten, werden so vermieden. Auch die Wartung der Software wird so vereinfacht, weil Bugs einfacher gefunden und behoben werden können.

Clean-Code-Prinzipien im Überblick

Aber wie schreibt man eigentlich sauberen Code? Bei Clean Code geht es darum, bestimmte Leitgedanken der Programmierung zu berücksichtigen. Es geht weniger um konkrete Anweisungen, was in einer bestimmten Situation wie programmiert werden soll, als um einen reflektierenden Blick auf die eigene Arbeitspraxis als Entwickler. Was Clean Code konkret bedeutet, ist daher innerhalb der Entwicklergemeinde umstritten: Was für die eine Gruppe Programmierer „clean“ ist, kann von anderen immer noch als „unsauber“ angesehen werden. Wie clean ein Code ist, ist daher immer auch ein Stück weit subjektiv. Wir stellen Ihnen im Folgenden einige bereits etablierte Clean-Code-Prinzipien vor, die von den meisten Entwicklern für sinnvoll befunden werden.

Code so einfach wie möglich: KISS

KISS (Keep it simple, stupid) ist eines der ältesten Clean-Code-Prinzipien. Es wurde bereits in den 1960er Jahren vom US-amerikanischen Militär angewandt. KISS erinnert Programmierer daran, Code so einfach wie möglich zu konstruieren. Unnötige Komplexität sollte vermieden werden. In der Programmierung gibt es nie nur einen Weg zur Lösung eines Problems. Eine Aufgabe kann immer mit verschiedenen Sprachen ausgedrückt und in unterschiedlichen Befehlen formuliert werden. Programmierer, die KISS befolgen, müssen sich daher stets fragen, ob sie ein bestimmtes Problem nicht auch einfacher lösen können.

Unnötige Wiederholungen vermeiden: DRY

DRY (Don’t repeat yourself) ist gleichsam eine Konkretisierung von KISS. Clean Code nach dem DRY-Prinzip bedeutet, dass eine Funktion eine einzige und damit eindeutige Darstellung innerhalb des Gesamtsystems haben sollte.

Hinweis

Der Gegenbegriff zu DRY ist WET (We enjoy typing). Als WET wird Code dann bezeichnet, wenn unnötige Dopplungen im Code auftauchen.

Folgendes Beispiel soll das DRY-Clean-Code-Prinzip verdeutlichen: Nutzername und Passwort werden im Code zweimal abgerufen, um dann für jeweils unterschiedliche Aktionen benutzt zu werden. Anstatt beide Prozesse separat zu programmieren, können diese in einer Funktion gebündelt werden. Aus einem „feuchten“ WET-Code mit Redundanzen wird so ein „trockener“ DRY-Code.

WET-Code:

//Variante A
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.post(user).then(/*Variante A*/);
//Variante B
let username = getUserName();
let password= getPassword();
let user = { username, password};
client.get(user).then(/*Variante B*/);

DRY Code:

function getUser(){
    return {
        user:getUserName();
        password:getPassword();
    }
}
//Variante A
client.post(getUser()).then(/*Variante A*/ );
//Variante B
client.get(getUser()).then(/*Variante B*/);

Löschen, was nicht gebraucht wird: YAGNI

Hinter dem Clean-Code-Prinzip YAGNI (You aren’t gonna need it) steckt folgende Idee: Ein Entwickler sollte zusätzliche Funktionalitäten erst dann zum Code hinzufügen, wenn sie notwendig werden. YAGNI ist eng verbunden mit den Methoden der agilen Software-Entwicklung. Anstatt in der Entwicklung von einem Gesamtkonzept auszugehen, geht es bei der Programmierung nach dem YAGNI-Prinzip darum, die Architektur der Software in kleinen Schritten aufzubauen, um so auf Probleme dynamisch und einzelfallbezogen reagieren zu können. Clean Code ist also immer dann produziert, wenn das zugrundeliegende Problem möglichst effizient gelöst wurde.

Lesbarkeit vor Prägnanz

Code muss funktionieren und von der ausführenden Maschine verstanden werden. Aber insbesondere dann, wenn Sie mit mehreren Personen an einem Projekt arbeiten, müssen auch andere Entwickler den Code verstehen können. Deshalb ist Lesbarkeit in der Software-Entwicklung immer wichtiger als ein möglichst prägnanter Code. Es hat keinen Sinn, prägnanten Code zu schreiben, wenn andere Entwickler ihn nicht verstehen. Ein gutes Clean-Code-Beispiel für Lesbarkeit ist die Benennung von Variablen.

Ein Variablenname sollte immer aus sich heraus verständlich sein. Die folgende Variable ist ohne Hintergrundwissen und Erklärung nicht verständlich:

int d;

Mit folgender Namensgebung ist die gleiche Variable hingegen selbsterklärend:

int elapsedTimeinDays;
War dieser Artikel hilfreich?