Clean Code – Prinzipien zum sauberen Programmieren

Entwickler wissen wie es ist, wenn man sich durch unsauberen Code durcharbeiten muss. Der Code ist „schwer“ zu lesen und es macht auch recht wenig Spaß. Man wird dadurch gebremst und die Produktivität sinkt auch bis in den Keller. Nach und nach häufen sich Berge von diesen Codeschnipseln an und der Code wird dadurch nicht mehr wartbar.

Wie kann man denn nun gegen diese Unsauberkeit entgegenwirken? Es gibt sehr viele Prinzipen im „Clean Code“, die gegen die unsaubere Programmierung wirken sollen. Einige dieser Prinzipien werde ich meinen nächsten Artikeln erläutern. Es sind sehr viele, wobei auch einige umstritten, sehr schwer anzuwenden oder auch nicht eindeutig sind und somit wegfallen. Aber darüber hinaus gibt es noch genug Prinzipien, die man erklären kann, versprochen ;) .

Die Prinzipen des „Clean Code“ beschreiben Strukturen/Architekturen in der objektorientierten Softwareentwicklung auf Quellcodeebene. Das Ziel dieser Prinzipien ist es, für lose Kopplung und verständliche Strukturen zu sorgen bzw. diese Strukturen wieder herzustellen.

Nun möchte ich euch die grundlegenden Dinge erklären, die eingehalten werden müssen, um die Wartbarkeit des Codes zu gewährleisten. Also ein erster Schritt in die richtige Richtung. Im Nachfolgenden werde ich euch die Prinzipen „Don´t Repeat Yourself“ (DRY) und „Keep it Simple, Stupid“ (KISS) erläutern.

Grundlegende Dinge

Als erstes ist es wichtig, einheitliche Bezeichner zu wählen, ob für Klassen, Methoden oder Attribute. Dies ist sehr wichtig, weil Entwickler Code ca. zehn- bis fünfzehnmal öfter lesen als schreiben. Hat man bspw. eine Klasse Auto mit den Attributen attr1, attr2, … muss man den Code lesen und schauen, was nun diese Attribute darstellen sollen. Heißen die Attribute anstatt der oben genannten aber nun hersteller, typ, …, weiß man gleich was gemeint ist und kann den Code weiterlesen ohne einen Zwischenstopp einzulegen. Dies gilt aber wie oben schon erwähnt nicht nur für Attribute einer Klasse oder Methode, sondern auch für alle anderen Elemente, bspw. die Klassen und Methoden selbst. Darum ist es wichtig gründlich darüber nachzudenken wie man diese Elemente bezeichnet.

Ebenfalls ist es wichtig die Verständlichkeit von Methoden zu gewährleisten. Es soll eigentlich so sein, dass man sich eine Methode einmal durchliest und hinterher weiß, was in diese Methode genau geschieht. Deswegen sollten Methoden von der Größe her überschaubar bleiben. Methoden sollten ebenso immer nur eine Funktion erledigen. Ganz nach dem Prinzip „principle oft the least surprise“. Wenn ich also die Methode getCars() aufrufe, gehe ich davon aus, dass ich Autos bekomme und keine Pferde. Ebenfalls muss man davon ausgehen können, dass keine Seiteneffekte auftreten. Wie schreib ich denn nun meine Methode bzw. Methoden? „Clean Code“ besagt, dass man seine Funktionen folgender Maßen schreiben soll:

  1. „niladisch“ – Funktion ohne Übergabe von Parameter
  2. „monadisch“ – Funktion mit Übergabe eines Parameters
  3. „dyadisch“ – Funktion mit Übergabe mehrerer Paramater

und man für die Verständlichkeit nicht mehr als 2 Parameter in einer Methode verwenden soll.

Fazit: Bezeichnungen von Klassen, Methoden und Variablen durchdenken um das Lesen des Codes zu beschleunigen.

Kommen wir zu den Kommentaren. Sind diese überhaupt nötig? Der Code sollte so geschrieben sein, dass Kommentare nicht Not tun. Sind nun doch Kommentare nötig, sollten diese auch gut durchdacht sein. Unnötige oder sogar falsche Kommentare halten nämlich jeden Entwickler beim Lesen von Code auf. Grundsätzlich kann man Kommentare reduzieren, indem man Klassen, Methoden und Variablen gut durchdacht benennt. Man schreibt anstatt:

//Strecke in Kilometer
int distance = 0;
 
dies:
 
int distanceInKM = 0;

Somit wäre schon einmal dieser Kommentar nicht mehr nötig. Allgemein erkennt man an vielen Kommentaren, dass der Sinn und Zweck durch den Code nicht erkennbar ist und der Code schlecht geschrieben wurde. Sind die Kommentare auch noch an falscher Stelle, ist das der absolute Super-Gau ;) .

Fazit: Bei gut geschriebenem Code sind somit Kommentare überflüssig. Lediglich ein Kommentar im Header einer Klasse zu kurzen Klassenbeschreibung ist meiner Meinung nach eine feine Sache.

DRY – Don´t Repeat Yourself

Eines der wichtigsten und ältesten Prinzipien  von Clean Code ist DRY – Don´t Repeat YourselfWiederhole dich nicht. Dieses Prinzip besagt, dass man keine Dopplungen(Redundanzen) im Code haben soll bzw. ihn reduzieren soll. Leichter gesagt als getan, denn dieses „einfache“ Prinzip ist das meist missachtete in der Softwareentwicklung. Nichts ist nämlich leichter als Codeschnipsel zu kopieren und wieder einzufügen (Copy&Paste).  Dies ist nämlich gerad dann der Fall, wenn es schnell gehen soll. Dadurch entsteht Inkonsistenz und auch eine höhere Fehleranfälligkeit.

Fazit: Auslagerung von Funktionen in andere Klassen, um diese Funktion aus mehreren Stellen im Programm aufzurufen ist eine feine Sache.

KISS – Keep it Simple, Stupid

Dieses Prinzip besagt, dass man Problemlösungen, die man für andere erstellt, nicht unnötig verkomplizieren soll. Das deutschsprachige Sprichwort: „In der Kürze liegt die Würde“ ist ein Korrelat zu diesem Prinzip ;) .

Aber nicht falsch verstehen, dass Sprichwort: „In der Kürze liegt die Würze“ soll nicht aussagen, dass man den einfachsten, weil am unaufwändigsten Weg beschreiben soll! Vielmehr soll es darum gehen, dass man Dinge so einfach hält wie nur möglich, um im Späteren sich(oder auch einen anderen) nicht groß den Kopf zerbrechen muss, um zu verstehen was da genau passiert. Wenn man nach einiger Zeit auf seinen eigenen Code schaut und nicht mehr auf einen Blick versteht, was da passiert, sollte man sich Gedanken machen! ;)

Fazit: Problemlösungen so einfach wie möglich halten!

In meinen nächsten Artikeln werde ich noch einige interessante Prinzipien erklären, über die man stolpern wird auf dem Weg zum Clean-Code-Developer.


Leave a Reply