Kaffeepause Nr. 103. Zur Verteidigung von „Clean Code“: 100 zeitlose Tipps

Quelle: Hackernoon „Clean Code“ von Robert C. Martin ist das am meisten empfohlene Programmierbuch aller Zeiten. Suchen Sie nach Büchern mit der Suchanfrage „Beste Bücher für Softwareentwickler“ und Sie werden dieses Buch mit ziemlicher Sicherheit in den Suchergebnissen finden. Und während einige Leute der Meinung sind, dass Clean Code es nicht wert ist, beachtet zu werden, würde ich argumentieren, dass solche Ansichten zutiefst falsch sind. Ja, einige der Ratschläge im Buch sind fragwürdig. Ja, einige Inhalte scheinen veraltet zu sein. Ja, einige Beispiele sind verwirrend. Es ist alles wahr. Aber lassen Sie uns die vielen nützlichen Tipps, die dieses Buch bietet, nicht so schnell außer Acht lassen! Clean Code nur wegen ein paar schlechten Ideen komplett zu ignorieren, ist nicht die beste Lösung. Schauen wir uns also ohne weitere Umschweife die besten Tipps an, die Clean Code zu bieten hat! Wir gehen jedes Kapitel durch und fassen die Ideen zusammen, die Onkel Bob und seine Co-Autoren anbieten.

Kapitel 1: Sauberer Code

1. Die Gesamtmenge an Unordnung nimmt mit der Zeit zu.

2. Die Wiederherstellung eines veralteten Systems von Grund auf ist sehr schwierig. Refactoring und inkrementelle Verbesserungen sind hierfür die beste Option.

3. In einer unübersichtlichen Codebasis können Aufgaben, die nur wenige Stunden dauern sollten, Tage oder Wochen in Anspruch nehmen.

4. Nehmen Sie sich die Zeit, schnell zu handeln.

5. Sauberer Code macht eines gut. Schlechter Code versucht zu viel.

6. Sauberer Code ist gut getestet.

7. Beim Lesen von gut geschriebenem Code macht jede Funktion ungefähr das, was Sie erwarten würden.

8. Wenn Sie mit einem Prinzip nicht einverstanden sind, das von jemandem mit langjähriger Erfahrung gelehrt wird, sollten Sie zumindest dessen Standpunkt berücksichtigen, bevor Sie ihn ignorieren.

9. Code wird viel häufiger gelesen als geschrieben.

10. Code, der leichter zu lesen ist, lässt sich leichter ändern.

11. Hinterlassen Sie die Codebasis besser, als Sie sie vorgefunden haben (Pfadfinderregel).

Kapitel 2: Die Bedeutung von Namen

1. Wählen Sie Ihre Variablennamen sorgfältig aus.

2. Die Auswahl guter Namen ist schwierig.

3. Der Name einer Variablen oder Funktion sollte angeben, was sie ist und wie sie verwendet wird.

4. Vermeiden Sie die Verwendung von aus einem Zeichen bestehenden Variablennamen, mit Ausnahme häufig verwendeter Namen, z. B. i für eine Zählervariable in einer Schleife.

5. Vermeiden Sie die Verwendung von Abkürzungen in Variablennamen.

6. Variablennamen sollten aussprechbar sein, sodass Sie darüber sprechen und sie laut aussprechen können.

7. Verwenden Sie Variablennamen, die leicht zu finden sind.

8. Klassen und Objekte müssen Namen in Form von Substantiven haben.

9. Methoden- und Funktionsnamen müssen Verben oder Verb-Substantiv-Paare sein.

Kapitel 3: Funktionen

1. Funktionen sollten klein sein.

2. Die Funktion muss eine Aktion ausführen.

3. Funktionen müssen beschreibende Namen haben.

4. Extrahieren Sie den Code im if/else-Körper oder wandeln Sie die Anweisungen in klar benannte Funktionen um.

5. Begrenzen Sie die Anzahl der Argumente, die eine Funktion benötigt.

6. Wenn eine Funktion viele Konfigurationsargumente erfordert, sollten Sie erwägen, diese in einer einzigen Konfigurationsparametervariablen zu kombinieren.

7. Funktionen müssen rein sein, was bedeutet, dass sie keine Nebenwirkungen haben und ihre Eingabeargumente nicht ändern.

8. Die Funktion muss ein Befehl oder eine Abfrage sein, jedoch nicht beides gleichzeitig (Befehls-Abfrage-Trennung).

9. Es ist besser, Fehler und Ausnahmen aus dem Code zu entfernen, als Fehler im Code zu belassen.

10. Extrahieren Sie doppelten Code in klar benannte Funktionen (Wiederholen Sie sich nicht).

11. Unit-Tests erleichtern das Refactoring.

Kapitel 4: Kommentare

1. Kommentare können falsch sein. Möglicherweise sind sie von vornherein falsch oder sie sind zunächst korrekt und veralten dann mit der Zeit, wenn sich der Code ändert.

2. Verwenden Sie Kommentare, um zu beschreiben, warum es so geschrieben ist, anstatt zu erklären, was passiert.

3. Kommentare können oft vermieden werden, indem klar benannte Variablen verwendet und Codeabschnitte in klar benannte Funktionen extrahiert werden.

4. Stellen Sie TODO-Kommentaren konsistente Präfixe voran, um sie leichter auffindbar zu machen. Überprüfen und bereinigen Sie Ihre TODO-Kommentare regelmäßig.

5. Verwenden Sie Javadocs nicht nur, um sie zu nutzen. Kommentare, die beschreiben, was eine Methode tut, welche Argumente sie akzeptiert und was sie zurückgibt, sind bestenfalls überflüssig und im schlimmsten Fall irreführend.

6. Kommentare sollten alle relevanten Informationen und Kontexte enthalten, die der Leser benötigt. Seien Sie nicht faul, wenn Sie einen Kommentar schreiben.

7. Protokollkommentare und Kommentare des Dateiautors sind aufgrund der Versionskontrolle und der Git-Schuldzuweisung nicht erforderlich.

8. Kommentieren Sie toten Code nicht aus. Löschen Sie es einfach. Wenn Sie glauben, dass Sie den Code in Zukunft benötigen werden, ist die Versionskontrolle genau das Richtige für Sie.

Kapitel 5: Formatierung

1. Wählen Sie als Team einen Satz Regeln für die Formatierung Ihres Codes aus und wenden Sie diese Regeln dann konsequent an. Egal mit welchen Regeln Sie einverstanden sind, Sie müssen zu einer Einigung kommen.

2. Verwenden Sie automatische Codeformatierung und einen Codeanalysator. Verlassen Sie sich nicht darauf, dass die Leute jeden Formatierungsfehler manuell finden und beheben. Dies ist ineffizient, unproduktiv und eine Zeitverschwendung bei der Überprüfung des Codes.

3. Fügen Sie vertikale Leerzeichen zwischen Codezeilen hinzu, um zusammengehörige Codeblöcke visuell zu trennen. Sie müssen lediglich eine neue Linie zwischen den Gruppen erstellen.

4. Kleine Dateien sind einfacher zu lesen, zu verstehen und zu verschieben als große Dateien.

5. Variablen sollten in der Nähe ihres Verwendungsortes deklariert werden. Bei kleinen Funktionen befindet sich dies normalerweise am oberen Rand der Funktion.

6. Formatieren Sie auch kurze Funktionen oder if-Anweisungen korrekt, anstatt sie in eine Zeile zu schreiben.

Kapitel 6: Objekte und Datenstrukturen

1. Die Implementierungsdetails in einem Objekt müssen hinter der Schnittstelle des Objekts verborgen sein. Indem Sie eine Schnittstelle zur Verwendung durch Verbraucher eines Objekts bereitstellen, erleichtern Sie die spätere Umgestaltung von Implementierungsdetails, ohne dass es zu bahnbrechenden Änderungen kommt. Abstraktionen erleichtern das Refactoring.

2. Jeder Code sollte keine Kenntnis von den Interna des Objekts haben, mit dem er arbeitet.

3. Wenn Sie mit einem Objekt arbeiten, sollten Sie es auffordern, einen Befehl oder eine Abfrage auszuführen, anstatt es nach seinen Interna zu fragen.

Kapitel 7: Fehler korrigieren

1. Die Fehlerbehandlung sollte den restlichen Code im Modul nicht beeinträchtigen.

2. Es ist besser, Fehler und Ausnahmen aus dem Code zu entfernen, als Fehler im Code zu belassen.

3. Schreiben Sie Tests mit Fehlern, um sicherzustellen, dass Ihr Code diese erkennt und nicht übersieht.

4. Fehlermeldungen sollten informativ sein und den gesamten notwendigen Kontext enthalten, den jemand möglicherweise für eine effektive Fehlerbehebung benötigt.

5. Durch das Einbetten von Drittanbieter-APIs in eine dünne Abstraktionsschicht wird es einfacher, eine Bibliothek in Zukunft durch eine andere zu ersetzen.

6. Durch das Einhüllen von Drittanbieter-APIs in eine dünne Abstraktionsschicht wird es einfacher, die Bibliothek beim Testen nachzuahmen.

7. Verwenden Sie das Sonderfallmuster oder das Nullobjektmuster, um außergewöhnliches Verhalten zu behandeln, beispielsweise wenn bestimmte Daten nicht vorhanden sind.

Kapitel 8: Grenzen

1. Bibliotheken von Drittanbietern tragen dazu bei, die Produktbereitstellung zu beschleunigen, indem sie Ihnen die Auslagerung verschiedener Aufgaben ermöglichen.

2. Schreiben Sie Tests, um sicherzustellen, dass Sie die Drittanbieterbibliothek korrekt verwenden.

3. Verwenden Sie das Adaptermuster, um die Lücke zwischen der API einer Drittanbieterbibliothek und der API, die Sie haben möchten, zu schließen.

4. Durch das Einbetten von Drittanbieter-APIs in eine dünne Abstraktionsschicht wird es einfacher, eine Bibliothek in Zukunft durch eine andere zu ersetzen. (Wiederholung aus Kapitel 7)

5. Durch das Einhüllen von Drittanbieter-APIs in eine dünne Abstraktionsschicht wird es einfacher, die Bibliothek beim Testen nachzuahmen. (Wiederholung aus Kapitel 7)

6. Versuchen Sie, Ihrer Bewerbung nicht zu viele Informationen über die Details einer Drittanbieterbibliothek mitzuteilen.

7. Es ist besser, sich auf das zu verlassen, was man kontrolliert, als auf das, was man nicht kontrolliert.

Kapitel 9: Unit-Tests

1. Testcode sollte genauso sauber sein wie Produktionscode (mit einigen Ausnahmen, die normalerweise mit Speicher oder Effizienz zusammenhängen).

2. Wenn sich der Produktionscode ändert, ändert sich auch der Testcode.

3. Tests tragen dazu bei, dass Ihr Produktionscode flexibel und wartbar bleibt.

4. Mithilfe von Tests können Sie Änderungen vornehmen und so sicher Refaktorierungen durchführen, ohne befürchten zu müssen, es selbst nicht zu bemerken.

5. Strukturieren Sie Ihre Tests nach dem Muster „Arrange-Act-Assert“ (auch bekannt als Build-Operate-Check, Setup-Exercise-Verify oder Given-When-Then).

6. Verwenden Sie domänenspezifische Funktionen, um das Schreiben und Lesen von Tests zu vereinfachen.

7. Bewerten Sie ein Konzept pro Test.

8. Tests müssen schnell sein.

9. Tests müssen unabhängig sein.

10. Tests müssen wiederholbar sein.

11. Tests sollten keine Bestätigung erfordern.

12. Tests sollten zeitnah geschrieben werden, kurz vor oder nach dem Schreiben des Produktionscodes und nicht erst Monate später.

13. Wenn Ihre Tests schlecht sind, müssen Sie damit rechnen, dass Ihr Code Fehler enthält.

Kapitel 10: Klassen

1. Die Klassen sollten klein sein.

2. Klassen sollten nur für eine Sache zuständig sein und nur einen Grund zur Änderung haben (Einzelverantwortungsprinzip).

3. Wenn Sie keinen klaren Namen für die Klasse finden, ist sie wahrscheinlich zu groß.

4. Ihre Arbeit endet nicht, wenn Sie einen Code zum Laufen bringen. Der nächste Schritt besteht darin, den Code umzugestalten und zu bereinigen.

5. Wenn Sie in Ihrer Anwendung viele kleine Klassen anstelle mehrerer großer Klassen verwenden, verringert sich die Menge an Informationen, die ein Entwickler verstehen muss, wenn er an einer bestimmten Aufgabe arbeitet.

6. Wenn Sie über eine gute Testsuite verfügen, können Sie große Klassen sicher in kleinere aufteilen.

7. Klassen sollten für Erweiterungen offen, für Änderungen jedoch geschlossen sein (Offen-Geschlossen-Prinzip).

8. Schnittstellen und abstrakte Klassen schaffen Nähte, die das Testen erleichtern.

Kapitel 11: Systeme

1. Verwenden Sie die Abhängigkeitsinjektion, um Entwicklern die Flexibilität zu geben, jedes Objekt mit der entsprechenden Schnittstelle an eine andere Klasse zu übergeben.

2. Verwenden Sie die Abhängigkeitsinjektion, um Schnittstellen zwischen Objekten in Ihrer Anwendung zu erstellen und so das Testen zu vereinfachen.

3. Softwaresysteme sind nicht wie ein Gebäude, das im Voraus entworfen werden muss. Sie ähneln eher Städten, die im Laufe der Zeit wachsen und sich an aktuelle Bedürfnisse anpassen.

4. Verschieben Sie die Entscheidungsfindung bis zum letzten kritischen Moment.

5. Verwenden Sie eine domänenspezifische Sprache, damit Domänenexperten und Entwickler dieselbe Terminologie verwenden.

6. Machen Sie Ihr System nicht zu kompliziert. Verwenden Sie das Einfachste, was funktioniert.

Kapitel 12: Bereitstellung

1. Systeme, die nicht getestet werden können, können nicht verifiziert werden, und Systeme, die nicht verifiziert werden können, sollten niemals eingesetzt werden.

2. Das Schreiben von Tests führt zu einem besseren Design, da einfach zu testender Code häufig Abhängigkeitsinjektion, Schnittstellen und Abstraktion verwendet.

3. Eine gute Reihe von Tests beseitigt die Angst, dass Ihre Anwendung beim Refactoring kaputt geht.

4. Das Duplizieren von Code birgt ein höheres Risiko, da es mehr Stellen im Code gibt, die geändert werden können, und noch mehr Stellen, an denen Fehler versteckt werden können.

5. Der Code, den Sie jetzt schreiben, ist leichter zu verstehen, da Sie tief in sein Verständnis eingebunden sind. Für andere ist es nicht einfach, schnell das gleiche Verständnisniveau zu erreichen.

6. Der größte Teil der Kosten eines Softwareprojekts hängt mit der langfristigen Wartung zusammen.

7. Tests dienen als lebendige Dokumentation dafür, wie sich Ihre Anwendung verhalten sollte (und tut).

8. Gehen Sie nicht weiter, sobald Ihr Code funktioniert. Nehmen Sie sich die Zeit, es klarer und verständlicher zu machen.

9. Die nächste Person, die Ihren Code in naher Zukunft liest, werden höchstwahrscheinlich Sie sein. Seien Sie freundlich zu Ihrem zukünftigen Selbst, indem Sie leicht verständlichen Code schreiben.

10. Widerstehen Sie dem Dogma. Seien Sie pragmatisch.

11. Es dauert Jahrzehnte, um ein wirklich guter Softwareentwickler zu werden. Sie können Ihre Lernkurve beschleunigen, indem Sie von den Experten in Ihrer Umgebung lernen und häufig verwendete Entwurfsmuster erlernen.

Kapitel 13: Parallelität

1. Parallelen Code zu schreiben ist schwierig.

2. Gelegentliche Fehler und Probleme, die schwer zu reproduzieren sind, sind oft Parallelitätsprobleme.

3. Tests garantieren nicht, dass Ihre Anwendung fehlerfrei ist, aber sie minimieren das Risiko.

4. Erfahren Sie mehr über häufige Parallelitätsprobleme und ihre möglichen Lösungen.

Kapitel 14: Sequentielle Verfeinerung

1. Sauberer Code beginnt normalerweise nicht mit einer leeren Tafel. Sie schreiben zunächst eine grobe Lösung und überarbeiten sie dann, um sie sauberer zu machen.

2. Es ist ein Fehler, mit der Arbeit am Code aufzuhören, sobald er funktioniert. Nehmen Sie sich die Zeit, es noch besser zu machen, nachdem es bereits funktioniert.

3. Die Unruhen nehmen allmählich zu.

4. Wenn Sie sich in der Klemme befinden, dass das Hinzufügen von Features zu schwierig ist oder zu lange dauert, hören Sie auf, Features zu schreiben, und beginnen Sie mit der Umgestaltung.

5. Inkrementelle Veränderungen sind oft besser als ein Neuaufbau von Grund auf.

6. Nutzen Sie Test-Driven Development (TDD), um eine große Anzahl sehr kleiner Änderungen vorzunehmen.

7. Zu einem guten Softwaredesign gehört die Trennung der Anliegen in Ihrem Code und die Aufteilung des Codes in kleinere Module, Klassen und Dateien.

8. Es ist einfacher, eine Sauerei sofort zu beseitigen, als sie später aufzuräumen.

Kapitel 15: JUnit-Interna

1. Negative Variablennamen oder bedingte Ausdrücke sind etwas schwieriger zu verstehen als positive.

2. Refactoring ist ein iterativer Prozess voller Versuch und Irrtum.

3. Hinterlassen Sie die Codebasis besser, als Sie sie vorgefunden haben (Pfadfinderregel). (Wiederholung aus Kapitel 1)

Kapitel 16: SerialDate umgestalten

1. Code-Reviews und Kritik an unserem Code machen uns besser, und das sollten wir begrüßen.

2. Sorgen Sie zuerst dafür, dass der Code funktioniert, und korrigieren Sie ihn dann.

3. Nicht jede Codezeile muss getestet werden.

Kapitel 17: Gerüche und Heuristiken

1. Clean Code ist kein Regelwerk, sondern ein Wertesystem, das die Qualität Ihrer Arbeit bestimmt.

[In diesem Kapitel listet Onkel Bob 66 ​​weitere Variationen seines Codes und seiner Heuristiken auf, von denen viele im Rest des Buches behandelt werden. Sie hier zu reproduzieren würde im Grunde bedeuten, den Namen jedes Elements zu kopieren und einzufügen, daher habe ich davon Abstand genommen. Ich würde vorschlagen, dass Sie stattdessen das Buch lesen!]

Abschluss

Lassen Sie uns dort aufhören, wo wir angefangen haben: Clean Code von Robert C. Martin ist das am meisten empfohlene Programmierbuch aller Zeiten. Dafür gibt es einen guten Grund.