Was ich von "Clean Code" gelernt habe

Manche von folgenden Texten sind direkt vom Buch "Clean Code" abgeschrieben. Manche habe ich selbst formuliert.

Clean Code

Motto: Software zum Laufen zu bringen und saubere Software zu schreiben, sind zwei ganz verschiedene Aktivitäten.

1. Sinnvolle Variablenamen
2. Kurze Funktion mit 0 - 2 Parametern
3. Ausnahmen sind besser als Fehlercodes
4. Don’t repeat yourself
5. In einer kleinen Funktion sind mehrmalige return, break und continue erlaubt
6. Verwenden Sie keinen Kommentar, wenn Sie eine Funktion oder eine Variable verwenden können
7. Vertikale und Horizontale Formatierungsregeln für das ganz Team
8. Vor- und Nachteil des Objects und der Datenstruktur
9. Trennung von Geschäftslogik und Fehlerhandlung
10. Eine Checked Exception zu einer untersten Funktion hinzufügen, verursacht eine Reihe von Änderungen auf alle Funktionen, die direkt oder indirekt diese Untenfunktion aufrufen
11. Das Einhüllen von Drittanbieter-APIs zählt zu den Best Practices
12. Keine Null übergeben und zurückgeben
13. Drittanbieter-Code wrappers, um die Funktionalität einzuschneiden
14. Tests schreiben, um die Verhalten der Drittanbieter-APIs zu verstehen
15. Plathhaltercode erstellen, um die Entwicklung nicht zu blockieren
16. Wir sollen vermeiden, dass unser Code zu viel über die Details der Drittanbieter-Software weiß.
17. Testcode ist genau so wichtig wie Produktionscode.
18. Lesbarkeit zeichnet einen sauberen Test aus.
19. Anzahl der assert-Anweisungen in einem Test minimiert werden sollte —> Ein Konzept pro Test
20. Sauere Tests sollen F(ast).I(ndependent).R(epatable).S(elf-validating).T(imely) folgen 
21. Die Klasse soll klein sein! —> Single Responsibility Prinzip
22. Software-Systeme sollten den Startup-Prozess von der Laufzeit-Logik trennen —> dafür hilft praktisch ein Dependency-Injection-Container(wie z.B. Spring)
23. Der wirkliche Wert eines AOP-Systems basiert auf seiner Fähigkeit, systemische Verhaltensweise klar und knapp zu beschreiben.
24. Schließlich ist die AspectJ-Sprache (siehe [AspectJ] und [Colyer]) das funktionsreichste Werkzeug zur Trennung von Concerns.
25. Es ist kein ​Big Design Up Front (BDUF​; »Großes Design vor der Arbeit«) erforderlich.
26. Eine optimale Systemarchitektur besteht aus modularisierten Concern-Domänen, die jeweils mit Plain Old Java Objects (oder anderen Objekten) implementiert werden. Die verschiedenen Domänen werden durch minimal invasive Aspekte oder aspektähnliche Tools integriert. Diese Architektur kann, wie der Code, testgesteuert entwickelt werden.
27. Entscheidungen​ bis zum letzten möglichen Moment aufzuschieben.
28. Eine gute DSL minimiert die »Kommunikationslücke« zwischen einem Domänenkonzept und dem Code.
29. Simple Design​ von Kent ​Beck: Es besteht alle Tests. Es enthält keine Duplizierungen. Es verkörpert die Absicht der Programmierer. Es minimiert die Anzahl der Klassen und Methoden.
30. Sie können Ihren Code auch ausdrucksstärker machen, indem Sie Ihre Funktionen und Klassen klein halten, indem Sie sich an die Standardnomenklatur halten, indem Sie die Unit-Tests geschreiben und indem Sie ausprobieren.
31. Eine hohe Anzahl von Klassen und Methoden ist manchmal die Folge eines sinnlosen Dogmatismus.
32. Ihr Thread-bezogener Code sollte klein und fokussiert sein.
33. Saubere Ergebnisse wären die Folge einer schrittweisen Verfeinerung.