Inhaltsverzeichnis
Kommentierungsstandards
Einheitliche Regeln für Quellcode-Kommentare und Dokumentationskommentare.
Grundprinzipien
Kommentare erklären WARUM, nicht WAS.
- Dokumentiere öffentliche APIs; halte interne Kommentare minimal
- Bevorzuge klaren Code über Kommentare
- Kommentiere nur das Nicht-Offensichtliche
- Standardsprache: Englisch
Inline-Kommentare
Verwende für:
- Intent (Absicht)
- Constraints (Einschränkungen)
- Trade-offs (Kompromisse)
- Edge Cases (Randfälle)
Vermeide: Code nacherzählen.
Beispiel: Gute vs. Schlechte Kommentare
(* SCHLECHT - Erzählt Code nach *) I := 0; (* Setze I auf 0 *) while I < Count do (* Schleife solange I kleiner als Count *) begin ProcessItem(Items[I]); (* Verarbeite Item *) Inc(I); (* Erhöhe I um 1 *) end; (* GUT - Erklärt Absicht und Constraint *) (* Process items in reverse order to maintain dependency chain. Items may reference later items, so forward processing would fail. *) for I := Count - 1 downto 0 do ProcessItem(Items[I]);
Doc-Kommentare (PasDoc)
Für Pascal/FPC wird PasDoc-Format verwendet.
Struktur
(* @abstract(Kurzbeschreibung der Funktion/Klasse) Ausführliche Beschreibung wenn nötig. Erkläre WANN und WARUM diese Funktion verwendet wird. @param(APath Pfad zur Eingabedatei. Muss existieren.) @param(AOptions Optionale Verarbeitungseinstellungen) @returns(True bei Erfolg, False bei Validierungsfehler) @raises(EFileNotFound wenn APath nicht existiert) @raises(EAccessDenied bei fehlenden Berechtigungen) @seealso(ProcessDirectory für Verzeichnisverarbeitung) Security: - CWE-22: Pfad wird gegen Traversal validiert *) function ProcessFile(const APath: string; AOptions: TOptions): Boolean;
Pflicht-Tags
| Tag | Wann | Beschreibung |
|---|---|---|
@abstract | Immer | Einzeilige Kurzbeschreibung |
@param | Bei Parametern | Jeder Parameter einzeln |
@returns | Bei Funktionen | Rückgabewert erklären |
@raises | Bei Exceptions | Jede mögliche Exception |
Optionale Tags
| Tag | Wann | Beschreibung |
|---|---|---|
@seealso | Bei verwandten Funktionen | Querverweise |
@deprecated | Bei veralteten APIs | Ersatz angeben |
@since | Bei neuen APIs | Version der Einführung |
@note | Bei wichtigen Hinweisen | Besondere Beachtung |
@warning | Bei Fallstricken | Mögliche Probleme |
Klassen-Dokumentation
(* @abstract(DateEdit Control für Datums-Eingabe mit Kalender-Popup) TWvdSDateEdit bietet ein Eingabefeld für Datumsauswahl mit: - Direkter Texteingabe mit Format-Validierung - Kalender-Popup für visuelle Auswahl - Datums-Range-Validierung (Min/Max) @bold(Verwendung:) - In Formularen für Datumseingabe - Als Filter in Datenansichten - Für Zeitraum-Auswahl (von/bis) @bold(Beispiel:) @longcode(# DateEdit := TWvdSDateEdit.Create(Self); DateEdit.MinDate := EncodeDate(2000, 1, 1); DateEdit.MaxDate := Now; DateEdit.OnDateChanged := @HandleDateChanged; #) @seealso(TWvdSTimeEdit für Zeitauswahl) @seealso(TWvdSDateTimePicker für kombinierte Auswahl) *) TWvdSDateEdit = class(TWvdSCustomEdit)
Methoden-Dokumentation
(* @abstract(Validiert den eingegebenen Datumswert) Prüft ob das eingegebene Datum: - Im korrekten Format ist - Innerhalb von MinDate/MaxDate liegt - Ein gültiges Datum darstellt (z.B. kein 31. Februar) @param(AValue Der zu validierende Datumswert) @param(AError Fehlermeldung wenn Validierung fehlschlägt) @returns(True wenn Datum gültig, False bei Fehler) @note(Leere Eingabe gilt als gültig wenn AllowEmpty = True) *) function ValidateDate(const AValue: TDateTime; out AError: string): Boolean;
Property-Dokumentation
(* @abstract(Minimales erlaubtes Datum) Legt das früheste auswählbare Datum fest. Eingaben vor diesem Datum werden abgelehnt. @seealso(MaxDate für obere Grenze) *) property MinDate: TDateTime read FMinDate write SetMinDate;
Review-Checkliste
[ ] Kommentar erklärt Intent/Trade-offs, nicht Mechanik [ ] Kommentar entspricht aktuellem Verhalten (kein Drift) [ ] Kommentar ist in Englisch und prägnant [ ] Öffentliche API hat vollständige Doc-Kommentare [ ] @param für jeden Parameter vorhanden [ ] @returns für Funktionen vorhanden [ ] @raises für mögliche Exceptions vorhanden [ ] Keine TODO/FIXME-Kommentare
Wann Kommentieren
Kommentieren
- Öffentliche APIs (Pflicht)
- Nicht-offensichtliche Algorithmen
- Workarounds für bekannte Bugs
- Sicherheits-relevante Entscheidungen
- Performance-Optimierungen mit Trade-offs
- Externe Abhängigkeiten
Nicht Kommentieren
- Offensichtlicher Code
- Selbsterklärender Code
- Temporärer Debug-Code (sollte entfernt werden)
- Auskommentierter Code (sollte gelöscht werden)
Sprach-spezifische Formate
| Sprache | Format | Beispiel |
|---|---|---|
| Pascal/FPC | PasDoc | (* @abstract(…) *) |
| Delphi | XMLDoc-style | / <summary>…</summary> |
| Rust | rustdoc |
Zuletzt geändert: den 29.01.2026 um 15:13