Die Matrix listet die Fähigkeiten auf, die CodeCharter mitbringt, und zeigt, wie sich die gängigsten .NET-Code-Quality-Tools dazu verhalten. Jede Zeile ist etwas, das CodeCharter kann; die anderen Spalten geben das reale, aktuelle Verhalten des jeweiligen Tools wieder.
Feature-Matrix
Legende: ✓ = unterstützt, partial = eingeschränkt oder indirekt, ✗ = nicht unterstützt.
| Feature | CodeCharter | Roslyn-Analyzer | SonarQube / Cloud | NDepend | Qodana |
|---|---|---|---|---|---|
| Quellcode verlässt die eigene Umgebung nie | ✓ | ✓ | nur self-hosted | ✓ | ✓ (Ergebnisse gehen an Qodana Cloud) |
| Kein Server oder Cloud-Backend zu betreiben | ✓ | ✓ | ✗ | ✓ | ✗ (Cloud-Konto; Self-Hosted ist ein Server) |
| Eigenständige CLI, die man bei Bedarf aufruft | ✓ | ✗ (läuft im Build) | ✗ (Scanner braucht einen Server) | ✓ | ✓ |
| Eigene Regeln in einer Text-DSL, ohne C#-Projekt, Build oder NuGet | ✓ | ✗ (Analyzer-Projekt + NuGet) | ✗ (Roslyn-Import oder Templates) | ✓ (CQLinq) | ✗ (FlexInspect / Structural Search) |
| Browser-Regeleditor mit Live-Validierung und Online-Spec-Check | ✓ | ✗ | ✗ | ✗ | ✗ |
| Eigene Regeln gegen Hit/Miss-Fälle spec-testen, lokal, in CI und im Browser, mit Verlauf | ✓ | ✗ | ✗ | ✗ | ✗ |
| Architektur- und Layering-Regeln in der Regelsprache | ✓ | ✗ | partial | ✓ | partial |
| Coupling- und OOP-Metriken (Instabilität, Abstraktheit, Kohäsion) im Modell | ✓ | ✗ | partial | ✓ | ✗ |
| Baseline-Gate, das nur bei neuen Findings fehlschlägt | ✓ | ✗ | ✓ | ✓ | ✓ |
| Führt eure Tests selbst aus und berechnet die Line-Coverage, ohne separates Coverage-Tool oder Report-Import | ✓ | ✗ | ✗ (importiert coverlet-/dotCover-Reports) | ✗ (importiert Reports) | ✗ (importiert Reports) |
| Regelprofile zentral verfassen, versionieren und teilen | ✓ | ✗ | ✓ | ✗ | ✓ (Cloud) |
| Versionierte, signierte Regelprofile mit Offline- / Air-Gap-Bundles | ✓ | ✗ | ✗ | ✗ | ✗ |
| SARIF-, JSON- und GitHub-Annotation-Ausgabe | ✓ | partial (SARIF über Build-ErrorLog) | ✓ | partial (SARIF-Import; eigener Report) | ✓ |
| MCP-Server, damit KI-Assistenten eure Regeln durchsetzen | ✓ | ✗ | ✓ | ✓ | ✗ |
| Abhängigkeitsgraph-Abfragen (Übersicht, Umgebung eines Typs, Auswirkungsradius) auf der Kommandozeile und als MCP-Tools für KI-Agenten | ✓ | ✗ | ✗ | partial (Dependency Graphs und CQLinq-Abfragen; keine CLI-/MCP-Abfrageoberfläche) | ✗ |
| Zentrales Audit-Log über Regel-, Profil- und API-Key-Aktivität, als CSV exportierbar | ✓ | ✗ | ✓ (Enterprise) | ✗ | partial (Cloud-Nutzungs-/Lizenzreporting) |
| Anforderungen als Dateien im Repository, an Code gebunden und im selben Pull Request gereviewt | ✓ | ✗ | ✗ | ✗ | ✗ |
| Opt-in-Nutzungs-Insights ohne Quellcode und ohne PII | ✓ | ✗ | ✓ (Server-Dashboards) | ✓ (Dashboards) | ✓ (Cloud-Dashboards) |
| Pauschale Organisations-Pläne in Teamgrößen-Staffeln (monatlich oder jährlich), kein Preis pro einzelnem Sitz | ✓ | kostenlos / OSS | pro Lines of Code | pro Seat | pro Contributor (ab 3) |
Wann CodeCharter die richtige Wahl ist
Wenn ihr eigene Regeln durchsetzen wollt, ohne C#-Analyzer-Projekte zu pflegen. CodeCharter-Regeln liegen in einer Textdatei, ohne Build- oder NuGet-Lifecycle.
Wenn ihr eure Regeln wie Code testen wollt. Jede Regel kann Hit/Miss-Spec- Fälle tragen, die lokal, in der CI und im Browser laufen, sodass eine Regeländerung, die das Richtige nicht mehr trifft, sofort auffällt.
Wenn ihr Regeln verfassen wollt, ohne den Browser zu verlassen. Der Portal- Editor validiert die DSL live und führt vor dem Veröffentlichen einen Online-Spec-Check aus.
Wenn ihr Architektur und Layering im Build durchsetzen wollt. Coupling und Abhängigkeiten sind Teil des Modells, und Layering-Regeln werden direkt in der DSL geschrieben.
Wenn ihr Regeln teamübergreifend und in der CI teilt, aber trotzdem abgeschottete Builds braucht. Profile sind versioniert und signiert und lassen sich als Offline-Bundles nutzen.
Wenn ihr keinen weiteren Server betreiben wollt. Die Analyse läuft lokal, der Quellcode verlässt die eigene Umgebung nie, und es gibt kein Dashboard, keine Datenbank und keinen Lizenzserver, den ihr selbst hosten oder betreiben müsst.
Wenn ihr Pull-Request-Gates auf geänderte Zeilen begrenzen wollt. Mit
--diff oder --git-ref gelten die gemeldeten Findings und das Fail-Gate nur
für die Zeilen, die eine Änderung berührt, und die GitHub Action kann die
Ergebnisse als Annotationen am Pull Request veröffentlichen.
Wenn ihr Coverage aus demselben Tool wollt, das eure Findings gated.
codecharter coverage findet eure Testprojekte, führt sie aus und berechnet
die Line-Coverage selbst, ohne coverlet-Setup und ohne Report-Import. Das
Gate hält wahlweise das ganze Repository auf einem Schwellenwert oder mit
--git-ref nur die Zeilen, die eine Änderung berührt, und das Portal liefert
Coverage-, Findings- und Test-Badges für eure README ohne fremden
Badge-Dienst. Siehe codecharter coverage.
Wenn ihr Regelunterstützung im Editor wollt. Die VS-Code-Erweiterung
bringt Vervollständigung, Diagnosen und Spec-Läufe für .cgr-Regeldateien in
den Editor und kann den geöffneten Workspace analysieren.
Wenn ihr gegen ein Lastenheft liefert oder einen Nachweis schuldet. Anforderungen liegen als Dateien im Repository, sind über Anchors an den Code gebunden, der sie einlöst, und werden von einem Menschen abgenommen, wobei die Evidenz dieser Abnahme mitgepinnt wird. Ändert sich der abgenommene Test oder die verankerte Coderegion, meldet der Lauf das, statt die Zusage still weiter als erfüllt zu führen. Siehe Requirements im Überblick.
Wenn ihr einen Pauschalpreis statt eines Preises pro Sitz wollt. CodeCharter wird pro Organisation lizenziert, monatlich oder jährlich, in nach Teamgröße gestaffelten Plänen (Starter bis 5, Team bis 10, Business bis 25 Entwickler-Sitze, Enterprise ohne Obergrenze). Innerhalb einer Staffel ändert sich der Preis nicht, wenn Entwickler dazukommen, und es gibt kein Nutzungs-Reporting pro Sitz. Die Staffelgrenze wird schlicht über die Organisations-Mitgliedschaft durchgesetzt. Siehe Was als Entwickler-Sitz zählt.
Alles auf dieser Seite lässt sich mit einer kostenlosen 7-Tage-Testphase ausprobieren, die automatisch bei der Registrierung startet, ohne Angabe von Zahlungsdaten.
Anforderungsverfolgung: eine andere Vergleichsgruppe
Die Matrix oben vergleicht CodeCharter mit Code-Quality-Werkzeugen, weil das für fast alle Zeilen die richtige Vergleichsgruppe ist. Für die Anforderungsverfolgung stimmt sie nicht: Roslyn-Analyzer, SonarQube, NDepend und Qodana treten dort nicht an, weil sie eine andere Aufgabe haben. Wer Anforderungen verfolgen will, vergleicht mit Ticket-Systemen wie Jira oder Azure Boards und mit Requirements- und ALM-Werkzeugen.
Der Unterschied liegt weniger im Funktionsumfang als im Ort. Ein ALM-Werkzeug verwaltet einen Anforderungsbestand neben dem Repository und braucht deshalb eine eigene Pflege, damit die Verbindung zum Code aktuell bleibt. In CodeCharter sind die Anforderungen Dateien im Repository, sie wandern mit dem Branch, sie werden im selben Pull Request gereviewt wie die Codeänderung, und derselbe Lauf, der eure Findings gated, prüft auch, ob die Bindung noch trägt.
Daraus folgt eine Begrenzung, die wir offen benennen: CodeCharter plant keine Arbeit. Zuweisungen, Status-Workflows, Schätzungen, Sprints und Boards bleiben in eurem Ticket-System. Was entfallen kann, ist ein separates Requirements-Werkzeug, dessen einziger verbliebener Zweck der Nachweis gegenüber Code ist. Die vollständige Abgrenzung, inklusive der Frage, wann sich der Aufwand nicht lohnt, steht unter Abgrenzung und Aufwand.
Wie es zusammenpasst
CodeCharter ersetzt nicht jedes oben genannte Tool. Ein praxistauglicher Stack für ein typisches .NET-Team:
- EditorConfig für Stileinstellungen im Editor.
- Microsoft.CodeAnalysis.NetAnalyzers als Roslyn-Basis für Sprache und Stil.
- CodeCharter für eigene Konventionen, Architektur und Layering, Komplexitätsschwellen und alles, was über Standard-Regelsätze hinausgeht.
Für den engen Fall von Layering-Zusicherungen innerhalb der Unit-Test-Suite könnt ihr mit Bibliotheken wie ArchUnitNET und NetArchTest Abhängigkeitsregeln als C#-Tests ausdrücken. Diese Bibliotheken decken den Test-Bibliotheks-Aspekt ab; CodeCharter ergänzt einen eigenständigen Analyzer, eine geteilte Regelsprache, Spec-Tests und CI-Gating darüber hinaus.