Clean Coding: Einführung und aussagekräftige Namen

29. Feber 2020
Clean Coding

In den nächsten Beiträgen möchte ich mich einem Thema widmen, mit dem ich mich persönlich in der Vergangenheit schon öfter auseinander gesetzt habe: Clean Coding.

Der „Erfinder“ von Clean Coding ist Robert C. Martin (auch Uncle Bob genannt) und ich kann sein Buch Clean Coding wirklich jedem Softwareentwickler ans Herz legen.

Bereits in der Einführung des Buches bringt er die ganze Sache auf den Punkt: Die einzig gültige Kennzahl für Code Qualität ist „What the fuck“ pro Minute. Wenn man darüber nachdenkt, kommt man über kurz oder lang zu dem Schluss, dass er Recht hat :-).

Oft wird ein Softwareentwickler daran gemessen, welche Tools er kennt und beherrscht, wie schnell er ist und wie viele Fehler er macht. Dabei wird oft vergessen, dass die Art und Weise wie er Anforderungen umsetzt, ob dies nachvollziehbar, testbar und nach längerer Zeit auch wartbar sind, einen wesentlichen Faktor darstellt.

Clean Coding sollte meiner Meinung nach eines der ersten Themen sein, mit der sich ein angehender Softwareentwickler auseinander setzen sollte. Wer gleich von Beginn an Wert darauf legt, wird es mittel- und langfristig wesentlich einfacher haben, als wenn er sich irgendwann umgewöhnen soll/muss und sich selbst über seinen zuvor erstellten Spaghetticode ärgern muss. Und je mehr derartiger Code sich anhäuft, desto komplizierter wird es, was sich dann schlußendlich auch in der Produktivität und somit in den Kosten bemerkbar macht.

Kapitel 1 – Einführung

Im ersten Teil stellt Robert C. Martin die Frage „was ist Clean Code“. Ich fasse die Antworten in ein paar Adjektiven zusammen: elegant, effizient, leserlich, erweiterbar, kompakt/konzentriert, verständlich. Manche dieser Wort mögen vielleicht auf den ersten Blick seltsam klingen (vor allem weil sie etwas aus dem Kontext gerissen wurden), aber der Sinn dürfte jedem, der sich darüber Gedanken macht, klar sein.

Kapitel 2 – Aussagekräftige Namen

Namen finden sich überall in der Softwareentwicklung: Dateien, Klassen, Funktionen, Variablen, Eigenschaften, … Umso wichtiger ist, dass alle diese einen korrekten Namen haben, sodass wenn man den Code liest, sofort klar ist, dass eine Funktion macht und für was eine Variable steht. Im Optimalfall soll sprechende Namen Kommentare überflüssig machen (worauf wir zu einem späteren Zeitpunkt nochmal kommen werden).

Ein paar no-go Beispiele:

  • Abkürzungen wie „d“, wenn die Variable aber eigentlich den heutigen Tag enthält
  • zu allgemein wie „list“, wenn es sich um eine Liste von Personen handelt
  • Magic numbers wie 7, wenn es um die Anzahl der Wochentage handelt
  • Fehlinformation wie „getPeople“, wenn aber Personen mit bestimmten Attributen zurückgegeben werden
  • Überflüssige Bezeichnung wie „CITY_TABLE“, wenn klar ist, dass es sich dabei um eine Tabelle in der Datenbank handelt

Nun ein paar Richtlinien für korrekte Benennungen:

  • Klassennamen bestehen aus ein oder mehreren Nomen, aber keine Verben. Beispiel: „Client“ oder „GarbageCollector“.
  • Funktionen bestehen aus einem Verb plus einem optionalen Nomen. Beispiel: „save“ oder „sendEmail“.
  • Gleiche Verben und Nomen für gleich Anwendungsfälle. Ein Paradebeispiel hierfür ist „fetch“, „retrieve“ und „get“.
  • Unterschiedliche Verben und Nomen für unterschiedliche Anwendungsfälle. Das Beispiel hier ist „add“ und „insert“. Wer C# kennt, dem sollte der Unterschied klar sein. Werden die Verben unterschiedlich verwendet, so führt dies zu Verwirrung.
  • Namen in Anlehnung an verwendete Design Patterns. Beispiel „AccountVisitor“, wenn der Visitor-Pattern verwendet wird.
  • Berücksichtigung des Kontextes: eine Variable „State“, die Teil der Klasse „Address“ ist hat eine andere Bedeutung als in der Klasse „Order“. Geht dieser Kontext nicht klar hervor, dann ist der Name nicht aussagekräftig genug.

Die Regeln für die Namensgebung sind nicht schwer und das Ergebnis sprich für sich.