Konfiguration

Formatter fuer konsistente Code-Qualitaet konfigurieren

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

Der groesste 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 fuer Formatter gehoert ins Repository, nicht in persoenliche IDE-Einstellungen. Eine Datei wie .prettierrc, .black oder eine vergleichbare Projektdatei sorgt dafuer, dass jeder Clone und jeder Agent denselben Standard sieht. Das verhindert, dass lokale Praeferenzen 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 spaeteres 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 fuer verschiedene Sprachen waehlen

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 Durchgaengigkeit: Einmal gewaehlt sollte der Formatter fuer das ganze Projekt gelten und nicht fuer einzelne Dateien oder Ordner ausgesetzt werden.

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

Fuer Python hat sich Black als Standard etabliert, weil es kaum Konfiguration erlaubt und damit Diskussionen ueber Stilfragen eliminiert. Fuer 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 muessen.

Formatter und Review-Workflow kombinieren

Der ideale Review-Prozess trennt inhaltliche von formattechnischen Aenderungen. Wenn Formatter strikt durchgesetzt sind, muss niemand mehr im Review sagen "hier fehlt ein Leerzeichen". Stattdessen koennen sich Reviewer auf Logik, Architektur und Risiken konzentrieren. Das beschleunigt nicht nur den Prozess, sondern hebt auch die Qualitaet 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 fuehrt den Formatter aus und praesentiert dann erst den Diff. Das stellt sicher, dass Agenten-Vorschlaege 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 eroeffnen.