33 lines
1.2 KiB
Markdown
33 lines
1.2 KiB
Markdown
# 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.
|