Coding Standards

Coding Standards sind Teamvereinbarungen darüber, wie Code geschrieben werden soll:

• Namenskonventionen (camelCase vs snake_case)
• Formatierung (Tabs vs Leerzeichen, Platzierung von Klammern)
• Code-Organisation (Dateistruktur, Modulgrenzen)
• Muster (wie mit Fehlern umgegangen wird, wie Tests strukturiert werden)

Standards ermöglichen kollektives Eigentum. Wenn Code überall gleich aussieht, kann jeder jeden Code lesen. Es gibt keine „Übersetzung" zwischen Bobs Stil und Alices Stil.

Standards reduzieren auch Reibung im Code-Review. Anstatt über Formatierung zu diskutieren, besprecht ihr Logik und Design. Das Bikeshedding entfällt.

Ohne Standards: Jede Datei fühlt sich anders an. Der Wechsel zwischen Modulen erfordert mentales Kontextwechseln. Code-Review wird zum Stilkrieg.

Mit Standards: Die Codebasis fühlt sich einheitlich an. Das Lesen von unbekanntem Code ist einfacher. Reviews konzentrieren sich auf das Wesentliche.

Nicht alle Konventionen sind gleich. Unterscheidet zwischen:

Semantische Standards: Beeinflussen Codeverhalten oder Wartbarkeit

• Fehlerbehandlungsmuster
• Logging-Konventionen
• Teststruktur
• API-Design-Muster

Stilistische Standards: Beeinflussen nur das Erscheinungsbild

• Formatierung (Einrückung, Zeilenlänge)
• Benennung (camelCase vs snake_case)
• Klammerplatzierung

Semantische Standards verdienen Diskussion. Wie das Team mit Fehlern umgeht, ist eine bedeutsame Entscheidung mit echten Konsequenzen.

Stilistische Standards sollten automatisiert werden. Nutzt Prettier, Black, gofmt – Tools, die Code automatisch formatieren. Verschwendet keine menschliche Zeit mit Tabs vs. Leerzeichen.

Das Ziel ist, Reibung zu beseitigen, nicht ein platonisches Ideal von Code-Stil zu erreichen.

Moderne Tools können die meisten Standards automatisch durchsetzen:

Formatierer: Prettier (JavaScript), Black (Python), gofmt (Go), rustfmt (Rust)

• Laufen beim Speichern oder als Pre-Commit-Hook
• Eliminieren Formatierungsdiskussionen vollständig

Linter: ESLint, Pylint, Clippy, RuboCop

• Erkennen Stilverstöße und potenzielle Bugs
• Konfigurierbar nach Teampräferenzen
• Laufen in CI, um nicht-konformen Code am Mergen zu hindern

Type Checker: TypeScript, mypy, Flow

• Erzwingen Typkonsistenz
• Fangen Fehler vor der Laufzeit ab

Pre-Commit-Hooks: Husky, pre-commit

• Führen Prüfungen vor dem Commit aus
• Fangen Probleme ab, bevor sie ins Repository gelangen

Einmal konfigurieren, für immer durchsetzen. Verlasst euch nicht auf menschliche Disziplin – automatisiert es.

Standards können starke Meinungen auslösen. Vermeidet endlose Debatten:

Beginnt mit bestehenden Konventionen. Wenn die Sprache oder das Framework einen Standardstil hat (Go, Rust), nutzt ihn einfach. Erfindet nichts neu.

Nutzt Industriestandards. Beliebte Linter-/Formatierer-Konfigurationen (Airbnb ESLint, Google Style Guide) sind kampferprobt.

Entscheidet schnell, passt später an. Wählt etwas Vernünftiges. Wenn es sich als problematisch erweist, ändert es. Blockiert den Fortschritt nicht, während ihr auf den perfekten Standard wartet.

Macht es demokratisch, aber entscheidungsfreudig. Lasst das Team über kontroverse Themen abstimmen. Die Mehrheit gewinnt. Die Minderheit akzeptiert die Entscheidung.

Erinnert euch an das Ziel. Standards existieren, um Reibung zu reduzieren, nicht um Präferenzen auszudrücken. Wenn eine Diskussion zu lange dauert, ist jede vernünftige Wahl in Ordnung.

Standards sollten dokumentiert werden – aber haltet sie lebendig:

Was dokumentiert werden sollte:

• Semantische Standards (wie mit Fehlern umgegangen wird, Testmuster)
• Begründung für nicht-offensichtliche Entscheidungen (warum wir X statt Y gewählt haben)
• Ausnahmen und wann Regeln gebrochen werden dürfen
• Wie Änderungen vorgeschlagen werden

Wo dokumentiert werden sollte:

• README oder CONTRIBUTING-Datei im Repository
• Wiki oder Team-Dokumentationsbereich
• Kommentare in der Linter-/Formatierer-Konfiguration

Haltet es aktuell. Veraltete Dokumentation ist schlimmer als keine Dokumentation. Wenn ihr einen Standard ändert, aktualisiert die Dokumentation.

Macht es auffindbar. Neue Teammitglieder sollten die Standards leicht finden. Vergrabt sie nicht in einem Wiki-Labyrinth.

Die beste Dokumentation ist der Code selbst. Wenn eure Standards automatisch durchgesetzt werden, demonstriert der Code, was akzeptabel ist.