Clean Code / Sauberer Code

Programmieren ist nicht gleich Programmieren!

Viele Entwickler programmieren mit dem Ziel, das Programm fertig zu schreiben und zum Laufen zu bekommen! Das ist der schlechteste Ansatz, den man wählen kann. Damit wird dem Kunden und dem Entwickler jegliche Möglichkeit genommen, das Programm zukunftssicher zu gestalten.

Ein guter Entwickler möchte sein Programm nicht nur runter programmieren, er möchte mit seinem Sourcecode eine Geschichte erzählen, so wie ein Geschichtsschreiber. Ab heute sind Sie ein Geschichtsschreiber, aber bitte kein Märchenerzähler.

Sprechende Namen

Damit sind wir am ersten Punkt angelangt! Ein guter Programmierer wählt immer sprechende Namen. Die Namen von Variablen, Methoden oder Klassen müssen das Vorhaben des Programmierers wiedergeben. Außerdem muss der gewählte Name drei Fragen beantworten können:

  • Warum existiert diese Variable, Methode, Klasse?
  • Was macht sie?
  • Wie wird sie benutzt?

Die gewählten Namen müssen leicht lesbar und aussprechbar sein, bitte keine unverständlichen Abkürzungen und Ausdrücke. Die Objektnamen und Klassennamen sind immer Substantive: „Customer, Page, Book, …“. Die Namen der Methoden sind immer Verben oder Verbalphasen: „addCustomer, removePage, …“.

Wichtig: Nehmen Sie sich genug Zeit für die Wahl, eines sprechenden Namens. Es lohnt sich!

Funktionen und Methoden

Eine gute Geschichte lässt sich leicht in Kapitel, Abschnitte, Absätze und Verse aufteilen. Das Gleiche gilt für den Sourcecode. Dieser lässt sich leicht in übersichtliche Methoden und Funktionen aufteilen.

Eine Methode oder Funktion sollte:

  • Kompakt sein (passt auf den Bildschirm)
  • Nur eine Operation ausführen (keine Seiteneffekte, nur ein Arbeitsschritt)
  • Lesbarkeit (von oben nach unten)
  • So wenig wie möglich Übergabeparameter / Argumente enthalten (keine Parameterübergaben ist am besten)
  • Niemals ein Eingangsparameter neu gestalten (keine direkte Modifikation)
  • Keine Flags benutzen (Flags sind hässlich)
  • Keine Seiteneffekte enthalten (Eine Methode macht nur das, was ihr Name verspricht)
  • Kein null zurück geben (sie bekommen früher oder später eine NullPointerException)
  • Eine Anfrage oder eine Operation sein, nicht beides gleichzeitig

Ausnahmen

In professionellen Fachzeitschriften finden Sie immer Fußnoten mit Zusatzinformationen zu dem Hauptlesestoff. Die Fußnoten können Sie überspringen, diese liefern Ihnen dennoch wichtige Informationen, wenn Sie ins Detail gehen möchten. Ähnlich verhält es sich mit Ausnahmen (Exception), sie sollten nicht oft oder gar nicht auftreten. Kommt es zu einer Ausnahme, sollte diese sehr informativ und tiefgründig sein.

Umgang mit Ausnahmen:

  • Isolieren Sie try / catch Bloks in Methoden
  • Verwenden Sie immer Laufzeitausnahmen (RuntimeExceptions)
  • Übergeben Sie immer den Kontext bei einer Ausnahme (niemals null)
  • Definieren Sie eigene Ausnahmen (Benutzen Sie eine Ummantelung [Wrapper]. Befreien Sie sich von fremden Abhängigkeiten / Ausnahmen)

Dokumentation

Wie sieht es mit Dokumentation aus? Eine Gegenfrage: Schreiben Sie zu einer Geschichte irgendeine Dokumentation? Der Sourcecode sollte selbsterklärend sein. Lassen sie die Dokumentation weg.

Sprachkonstrukte / Formatierung

Unterschiedliche Geschichtsschreiber schreiben unterschiedlich. Dennoch gibt es ein paar Leitlinien, an die man sich halten sollte.

  • Einen switch isolieren Sie immer in eine Funktion und liefern Sie das nötige Ergebnis
  • Versuchen Sie die Klassen klein zu halten, nicht mehr als 500 Zeilen
  • Maximal 100 bin 120 Symbole in einer Zeile
  • Funktionen, die voneinander abhängig sind, sollten sich in der Nähe befinden
  • Programmieren Sie immer gegen eine Schnittstelle, nicht gegen eine konkrete Implementierung
  • Bitte programmieren Sie keine Ketten (list.get(index).get(item).get(object).name();)

TDD – Test Driven Development

Eine echte Geschichte, die der Wahrheit entspricht, wird durch archäologische Ausgrabungen geprüft und bestätigt. Sourcecode sollte immer Tests unterzogen werden. Der beste Ansatz dafür ist Test-Gestützte-Entwicklung. Wer Test-Betrieben programmiert, produziert mit Sicherheit einen besseren Sourcecode, als derjenige der sich auf die Implementierung stürzt.

Axiome des TTD:

  • Schreiben Sie zuerst Test, dann den eigentlichen Code
  • Schreiben sie den Test bis zu Verweigerung (Kompilierung nicht mehr möglich)
  • Schreiben Sie nur so viel Code wie nur nötig, um den Test zu bestehen

Tests und das eigentliche Produkt werden zeitgleich geschrieben. Halten Sie ihre Tests sauber!

F.I.R.S.T.

Die Umsetzung der Tests können Sie nach der F.I.R.S.T. Spezifikation prüfen

  • F – Fast / Schnell (Die Tests laufen schnell ab)
  • I – Independent / Unabhängig (Keine Abhängigkeiten unter den Tests)
  • R – Repeatable / Wiederholbar (Unter beliebigen Umständen)
  • S – Self-Validating / Offensichtlich (Einfach: Bestanden JA / NEIN)
  • T – Timely / Rechtzeitig (Schreiben der Tests vor der eigentlichen Implementierung)

Neue Bibliotheken und Frameworks

Ein Schreiber entwickelt sich immer weiter, sein Text wird vollständiger und genauer. Ein Entwickler erweitert seine Möglichkeiten durch die Aneignung neuer Bibliotheken und Frameworks. Die beste Möglichkeit dies zu tun sind Training Tests.

  • Training Tests sind kostenlos
  • Sie sind nützlich und effektiv

Prüfung des Sourcecodes

Nach dem der Geschichtstext fertiggestellt wurde, muss dieser Korrektur gelesen werden. Um mögliche orthografische und inhaltliche Fehler zu beseitigen. Der Sourcecode muss ebenfalls geprüft werden.
Die wichtigste Aufgabe ist es sicher zu stellen, dass die Architektur so einfach wie möglich definiert wurde.
Definition der Einfachheit (Wichtigkeit von Oben nach Unten):

  • Sicherstellung der Testdurchläufe
  • Enthält keine Duplikate
  • Spiegelt das Vorhaben des Programmierers wieder
  • Benutzt minimale Anzahl an Klassen und Methoden

Schreiben Sie Ihre eigene Geschichte und behalten Sie dabei folgendes immer im Hinterkopf:

Den Sourcecode zum Laufen zu bringen ist nicht professionell! Testen Sie den Sourcecode und halten Sie ihn immer sauber!