Ohne --rules sucht die CLI nach einem rules/-Verzeichnis im aktuellen
Arbeitsverzeichnis. Über die Option --rules <dir> zeigen Sie auf ein
beliebiges Verzeichnis.
Ein lokales rules/-Verzeichnis ist der ältere Weg. Empfohlen wird die
Verwaltung der Regelmenge über Plattform-Profile
in .codecharter/config.yml. Profile und ein automatisch gefundenes
rules/-Verzeichnis schließen sich gegenseitig aus: Sobald Profile
konfiguriert sind, laufen ausschließlich deren Regeln, und ein lokales
rules/-Verzeichnis wird ignoriert, außer Sie geben explizit
--rules <dir> an, das immer gewinnt. Ohne konfigurierte Profile weist ein
Lauf mit nur eingebauten oder lokalen Regeln per Deprecation-Hinweis auf
Plattform-Profile hin. Das Layout unten gilt weiterhin für eigene Regeln, die
Sie im Repo halten, egal ob Sie sie über --rules laden oder in ein
lokales Profil bündeln.
Empfohlenes Layout im Repo
rules/
├── architecture/
│ ├── domain-must-not-reference-web.ccr
│ └── repository-naming.ccr
├── naming/
│ ├── no-manager-suffix.ccr
│ ├── no-manager-suffix.spec.md
│ └── async-suffix.ccr
└── team-conventions/
└── controller-action-limit.ccr
.codecharter/config.yml
Unterverzeichnisse unter rules/ sind frei wählbar. CodeCharter liest
rekursiv alle .ccr-Dateien. Ältere .cgr-Dateien aus der Zeit vor der
Umbenennung von CodeGuard zu CodeCharter werden zur Abwärtskompatibilität
weiterhin gelesen, damit bestehende Repositories nicht angepasst werden müssen.
Die Regel-ID ist der Dateiname ohne die Endung .ccr; die Namen der
Unterverzeichnisse haben keine Bedeutung. Diese IDs werden in
.codecharter/config.yml-Einträgen und Suppression-Kommentaren referenziert.
Vermeiden Sie deshalb gleiche Dateinamen in verschiedenen Ordnern.
Spec-Tests liegen als <regel-name>.spec.md neben der .ccr-Datei und
werden von codecharter test rekursiv gefunden.
rules/ initialisieren
codecharter init
Legt ein rules/-Verzeichnis mit zwei Beispiel-Regeln an, von dem aus Sie
weiter wachsen können.
.codecharter/config.yml
Die Repository-Konfiguration liegt unter .codecharter/config.yml. Neben anderen
Abschnitten schaltet ignore Regeln ab (optional auf einen Namespace oder
passende Entity-Namen beschränkt), und exclude nimmt ganze Pfade aus der
Analyse:
version: 1
ignore:
- rule: namespace-distance
in: Acme.Generated
- rule: async-suffix
exclude:
- "**/tests/**"
- "**/obj/**"
Den vollständigen Satz an Abschnitten (Profile, Parameter, Severities, Regel-Aktivierung und Pfad-Scopes) finden Sie unter Konfigurationsdatei.
Inline-Suppressions
Pro Stelle im Code:
// codecharter-disable-next-line datetime-direct-usage
var migrationTimestamp = DateTime.UtcNow;
Die Regel-ID im Kommentar muss exakt dem Dateinamen der Regel entsprechen, inklusive Groß- und Kleinschreibung. Siehe Suppressions für alle Varianten.
Plattform-Profile im Repo
Wenn Sie Plattform-Profile nutzen, listen Sie sie in .codecharter/config.yml;
codecharter.lock.json (pinnt jedes Profil über einen Content-Hash) und die
heruntergeladenen Regel-Bundles liegen beide unter .codecharter/:
.codecharter/
├── config.yml
├── codecharter.lock.json
└── cache/
Committen Sie config.yml und codecharter.lock.json; cache/ ist ein
lokaler Download-Cache und gehört nicht in die Versionsverwaltung (siehe
Konfigurationsdatei).
Multi-Repo und Monorepo
In einem Monorepo können Sie rules/-Verzeichnisse pro Sub-Projekt haben
und über --rules darauf zeigen. CodeCharter findet .codecharter/config.yml,
indem es von der analysierten Datei aufwärts sucht; eine Konfiguration im
Repository-Wurzelverzeichnis gilt damit für alles darunter.