# Code-Qualitaetsstandard

## Ziel

Der Client soll klein, pruefbar und wartbar bleiben. Kommentare sind keine
zweite Dokumentation und keine Erklaerung fuer selbsterklaerenden Code.

## Kommentarregel

- Kommentare bleiben nur bei Sicherheitsgrenzen, externen API-Eigenheiten,
  nicht offensichtlichen Entscheidungen und bewusstem Fehlertoleranz-Verhalten.
- Beschreibende Kommentare direkt neben selbsterklaerenden Anweisungen werden
  entfernt.
- Veraltete Kommentare werden im selben Pull Request wie die Codeaenderung
  geloescht oder aktualisiert.
- Architektur- und Betriebswissen gehoert in `docs`, nicht in lange
  Quellcodekommentare.

## Wiederkehrender Clean-up

Bei jeder Minor-Version wird ein kurzer Wartungsdurchlauf eingeplant:

1. Tote Konfiguration, nicht erreichbare Pfade und doppelte Hilfsfunktionen entfernen.
2. Kommentare gegen den aktuellen Code pruefen und ueberfluessige entfernen.
3. Formatierung und Benennung vereinheitlichen.
4. Release-Build und die relevanten Scan-Szenarien erneut ausfuehren.

## Sicherheitsausnahme

Kommentare, die vor einer unsicheren Aenderung schuetzen, bleiben erhalten.
Beispiele sind TLS-Kompatibilitaet, Secret-Schutz, Upload-Signaturpruefung und
deterministische Lastverteilung.