Konfiguration

Formatter für konsistente Code-Qualität konfigurieren

Formatter sind in QuantenRam nicht nur kosmetisch. Sie reduzieren Noise in Diffs, erzwingen gemeinsame Lesbarkeit im Team und schaffen eine neutrale Basis für Reviews. Wer seine Formatter bewusst wählt und durchsetzt, spart in realen Workflows erheblich Zeit beim Verstehen, beim Debuggen und beim Genehmigen.

Der grösste Fehler bei Formatting ist die halbe Konfiguration. Wenn ein Projekt theoretisch einen Formatter hat, aber Contributors unterschiedliche IDE-Einstellungen, Line-Endings oder Tab-Width nutzen, entsteht genau der Chaos-Zustand, den der Formatter verhindern sollte. Gute Formatter-Konfiguration ist deshalb immer projektweit, versioniert und automatisch durchgesetzt.

Formatter im Repository festlegen

Die Konfiguration für Formatter gehört ins Repository, nicht in persönliche IDE-Einstellungen. Eine Datei wie .prettierrc, .black oder eine vergleichbare Projektdatei sorgt dafür, dass jeder Clone und jeder Agent denselben Standard sieht. Das verhindert, dass lokale Präferenzen das Teamergebnis fragmentieren.

Pre-Commit oder CI durchsetzen

Formatter sollten nicht optional sein. Ein Pre-Commit-Hook oder ein CI-Schritt, der bei Format-Fehlern blockt, stellt sicher, dass nur sauber formatierter Code ins Repository gelangt. Das ist bequemer als späteres Nachformatieren in Reviews und verhindert Format-Commits, die die eigentliche Arbeit verschleiern.

Agenten und Formatter im Gleichschritt

Wenn du mit Agenten arbeitest, sollten diese den Formatter deines Projekts kennen und anwenden. In QuantenRam bedeutet das, dass Rules oder Commands den Formatter explizit nennen und Agenten-Ausgaben entsprechend strukturieren. So bleibt Code, den Agenten vorschlagen, konsistent mit menschlichen Contributions.

Formatters für verschiedene Sprachen wählen

Nicht jeder Formatter passt zu jedem Projekt. Die Wahl sollte nach Community-Standard, Geschwindigkeit und Konfigurierbarkeit erfolgen. Wichtiger als die spezifische Wahl ist jedoch die Durchgängigkeit: Einmal gewählt sollte der Formatter für das ganze Projekt gelten und nicht für einzelne Dateien oder Ordner ausgesetzt werden.

// .prettierrc - Beispiel fuer JavaScript/TypeScript
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5"
}

Für Python hat sich Black als Standard etabliert, weil es kaum Konfiguration erlaubt und damit Diskussionen ueber Stilfragen eliminiert. Für Rust ist rustfmt die klare Wahl, weil es offiziell und konsistent integriert ist. Die Entscheidung sollte immer darauf abzielen, dass neue Contributors wissen, was zu tun ist, ohne lange Dokumentation lesen zu müssen.

Formatter und Review-Workflow kombinieren

Der ideale Review-Prozess trennt inhaltliche von formattechnischen Änderungen. Wenn Formatter strikt durchgesetzt sind, muss niemand mehr im Review sagen "hier fehlt ein Leerzeichen". Stattdessen können sich Reviewer auf Logik, Architektur und Risiken konzentrieren. Das beschleunigt nicht nur den Prozess, sondern hebt auch die Qualität der Diskussionen.

# .github/workflows/format.yml - Beispiel CI-Check
name: Format Check
on: [push, pull_request]
jobs:
  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Check formatting
        run: |
          npm ci
          npm run format:check

In QuantenRam kannst du Commands definieren, die Formatter vor dem Vorschlag anwenden. Ein Command wie /format-and-propose führt den Formatter aus und präsentiert dann erst den Diff. Das stellt sicher, dass Agenten-Vorschläge immer den Projektstandards entsprechen, ohne dass du manuell nachformatieren musst.

Wenn du Formatter konfigurierst, denke an das Ziel: Jeder im Team sollte denselben Code sehen, egal ob er menschlich oder ein Agent ist. Formatter sind dazu da, Format-Fragen zu beenden, nicht um neue Debatten zu eröffnen.