1. Verständlichkeit vor Cleverness. Code sollte für andere Entwickler schnell verständlich sein. Bevorzuge explizite, nachvollziehbare Lösungen gegenüber cleveren Konstruktionen, deren Zweck sich erst durch längere Analyse erschließt.
2. Single Responsibility Principle. Jede Funktion, Klasse oder jedes Modul sollte eine klar definierte Verantwortung haben. Wenn eine Funktion validiert, Daten transformiert, Datenbankzugriffe ausführt und gleichzeitig Benachrichtigungen versendet, ist sie wahrscheinlich zu komplex.
3. DRY, aber mit Augenmaß. „Don't Repeat Yourself“ bedeutet, duplizierte Fachlogik zu vermeiden. Ähnlich aussehender Code sollte jedoch nicht zwangsläufig abstrahiert werden. Eine Abstraktion lohnt sich erst, wenn tatsächlich ein gemeinsames Konzept existiert.
4. KISS und YAGNI. Halte Lösungen so einfach wie möglich. Implementiere keine hypothetischen Anforderungen, unnötigen Abstraktionsschichten oder Erweiterungsmöglichkeiten, für die es noch keinen konkreten Bedarf gibt.
5. Aussagekräftige Namen. Variablen, Funktionen, Klassen und Module sollten ihre fachliche Bedeutung ausdrücken. Namen wie processData(), temp oder manager sind häufig zu unspezifisch. Bevorzuge Namen, die Absicht und Kontext vermitteln.
6. Kleine, fokussierte Funktionen. Funktionen sollten eine klar erkennbare Aufgabe erfüllen. Ihre Länge ist weniger entscheidend als ihre kognitive Komplexität, die Anzahl ihrer Verantwortlichkeiten und die Menge an implizitem Kontext, den man zum Verständnis benötigt.
7. Explizite Fehlerbehandlung. Fehler dürfen nicht stillschweigend ignoriert werden. Definiere klare Fehlerzustände, behandle erwartbare Fehler gezielt und vermeide pauschale Exception-Handler, die Probleme verschleiern.
8. Robuste Eingabevalidierung. Vertraue keinen externen Daten. Validere Eingaben an Systemgrenzen, prüfe Vorbedingungen und behandle ungültige Zustände kontrolliert. Interne Daten müssen nicht ohne Grund an jeder Stelle erneut validiert werden.
9. Keine unnötigen Seiteneffekte. Funktionen sollten möglichst klar erkennen lassen, ob sie Daten verändern, externe Systeme aufrufen oder persistenten Zustand beeinflussen. Reine Funktionen erleichtern Tests und Fehlersuche.
10. Lesbare Kontrollflüsse. Vermeide unnötige Verschachtelungen, komplexe Bedingungen und schwer nachvollziehbare Abbruchpfade. Guard Clauses und frühe Rückgaben können die Struktur deutlich verbessern.
11. Kommentare erklären das Warum. Guter Code erklärt möglichst selbst, was passiert. Kommentare sollten insbesondere fachliche Entscheidungen, nicht offensichtliche Einschränkungen und bewusst gewählte Workarounds erläutern. Veraltete Kommentare sind schlechter als keine Kommentare.
12. Keine Magic Values. Fachlich relevante Zahlen, Zeichenketten und Grenzwerte sollten als benannte Konstanten oder Konfigurationen definiert werden. Offensichtliche Werte müssen dagegen nicht künstlich abstrahiert werden.
13. Tests für Verhalten und Randfälle. Teste insbesondere fachliche Regeln, Grenzwerte, Fehlerfälle und kritische Integrationspunkte. Tests sollten das erwartete Verhalten absichern, nicht bloß die aktuelle Implementierung nachbilden.
14. Sicherheit als Standard. Verwende parametrisierte Datenbankabfragen, sichere Authentifizierung und Autorisierung, angemessene Geheimnisverwaltung und etablierte kryptografische Verfahren. Vermeide sensible Daten in Logs und Fehlermeldungen.
15. Konsistente Konventionen. Formatierung, Namensgebung, Projektstruktur und Fehlerbehandlung sollten innerhalb eines Projekts einheitlich sein. Automatisiere diese Regeln, wo sinnvoll, durch Formatter, Linter und statische Analyse.
16. Abhängigkeiten bewusst einsetzen. Jede zusätzliche Bibliothek erhöht Wartungsaufwand, Angriffsfläche und potenzielle Kompatibilitätsprobleme. Bevorzuge etablierte, gepflegte Abhängigkeiten und prüfe, ob eine zusätzliche Dependency tatsächlich notwendig ist.
17. Keine vorzeitige Optimierung. Optimiere nicht auf Verdacht. Wähle zunächst eine klare Lösung und verbessere die Performance anschließend anhand von Messungen, Profiling und konkreten Anforderungen.
18. Änderungen klein und nachvollziehbar halten. Jede Änderung sollte möglichst einen klaren Zweck verfolgen. Vermeide es, in einem Commit gleichzeitig Fachlogik umzubauen, Formatierung zu ändern und unabhängige Refactorings durchzuführen.