Automatisierte Formatierung und Linting als Team-Vereinbarung

Ziel

Review-Aufmerksamkeit auf Design und Korrektheit richten, indem Layout und mechanischer Stil zu einem gelösten, automatisierten Problem werden.

Voraussetzungen

Ein Formatter und ein Linter für jede Sprache im Repository, von der Kommandozeile aus lauffähig, mit der Konfiguration im Repository gespeichert.

Schritte

1. Eine .editorconfig für Einrückung, Zeilenenden und nachgestellte Leerzeichen ergänzen, damit sich Editoren einig sind, bevor irgendein Werkzeug läuft.
2. Einen Formatter pro Sprache wählen und ihn auf der gesamten Codebasis in einem einzigen Commit ausführen, der nichts anderes enthält.
3. Linter-Regeln stufenweise aktivieren: mit Korrektheitsregeln beginnen (ungenutzte Imports, undefinierte Namen, unerreichbarer Code), dann Stilregeln ergänzen, die das Team akzeptiert. PEP 8 selbst sagt, dass seine Vorgaben der Konsistenz innerhalb eines Projekts weichen.
4. Beide Werkzeuge als Pflichtprüfung in der Pipeline laufen lassen und, optional, in einem Pre-Commit-Hook.
5. Regeländerungen wie Codeänderungen behandeln: vorschlagen, reviewen, in einem Commit auf den gesamten Baum anwenden.

Erwartetes Ergebnis

Keine Review-Kommentare zu Abständen oder Import-Reihenfolge; Formatierungsdiffs verschwinden aus fachlichen Änderungen; neue Mitwirkende erhalten sofortiges, unpersönliches Feedback von den Werkzeugen.

Grenzen und Prüfbasis

Formatter entscheiden über Layout, nicht über Benennung oder Struktur; diese bleiben Review-Themen. Ein Linter mit Hunderten aktivierten Regeln erzeugt Rauschen, das Leute lernen zu ignorieren. Die zitierten Werkzeuge sind Beispiele; die Vereinbarung zählt mehr als das Werkzeug.