Erstes Finding fixen

CodeGuard liefert ein Finding. Was jetzt? Drei Reaktionen sind möglich: fixen, bewusst unterdrücken oder die Regel deaktivieren wenn sie nicht zum Team passt.

Ein Finding lesen

Beispiel-Ausgabe:

Acme.Domain/Calculations/PricingEngine.cs:42
    [warn] DateTime-Direct-Usage
    Direct calls to DateTime.Now/UtcNow/Today are untestable.
    Use System.TimeProvider (available since .NET 8) instead.

Das sagt dir:

• Datei und Zeile: PricingEngine.cs:42
• Severity: warn
• Regelname: DateTime-Direct-Usage (das ist der Slug, im Wiki suchbar)
• Beschreibung und Empfehlung direkt darunter

Variante A: fixen

Vor:

public class PricingEngine
{
    public decimal Calculate(decimal basePrice)
    {
        var now = DateTime.UtcNow;
        if (now.DayOfWeek == DayOfWeek.Sunday) return basePrice * 1.5m;
        return basePrice;
    }
}

Nach:

public class PricingEngine
{
    private readonly TimeProvider _time;
    public PricingEngine(TimeProvider time) => _time = time;

    public decimal Calculate(decimal basePrice)
    {
        var now = _time.GetUtcNow();
        if (now.DayOfWeek == DayOfWeek.Sunday) return basePrice * 1.5m;
        return basePrice;
    }
}

Test:

[Fact]
public void Sunday_Price_Is_Surcharged()
{
    var clock = new FakeTimeProvider();
    clock.SetUtcNow(new DateTimeOffset(2024, 1, 7, 12, 0, 0, TimeSpan.Zero)); // Sunday
    var engine = new PricingEngine(clock);
    engine.Calculate(100m).Should().Be(150m);
}

Beim nächsten codeguard analyze ist das Finding weg.

Variante B: bewusst unterdrücken

Manchmal hast du einen guten Grund die Regel hier nicht zu befolgen - z.B. in einer Migrations-Klasse die historisch ist und nicht angefasst wird.

Inline-Suppression direkt im Code:

// codeguard:disable DateTime-Direct-Usage, legacy migration code, do not touch
var migrationTimestamp = DateTime.UtcNow;

Die disable-Direktive gilt für die nächste Zeile. Für mehrere Zeilen:

// codeguard:disable-block DateTime-Direct-Usage, legacy block
var a = DateTime.Now;
var b = DateTime.UtcNow;
// codeguard:enable-block

Mehr Details unter Suppressions.

Variante C: Regel deaktivieren

Wenn ihr eine eingebaute Regel im ganzen Repo nicht haben wollt, deaktiviert sie in eurer .codeguard-Konfiguration:

[disable]
DateTime-Direct-Usage

Macht das nur wenn die Regel wirklich nicht zu eurem Team passt, nicht um eine Stelle zu vermeiden. Für eine konkrete Stelle ist die Inline-Suppression die richtige Wahl.

Reihenfolge der Reaktion

Faustregel:

1. Erst überlegen ob das Finding richtig ist. Steht es im Konflikt mit eurer expliziten Architektur-Entscheidung, ist die Regel falsch für euch. Dann Variante C.
2. Wenn die Regel richtig ist, aber die Stelle eine echte Ausnahme: Variante B mit Begründung im Kommentar.
3. Sonst: Variante A. Wenn ihr ein Finding zum Schweigen bringen müsst ohne dass dahinter eine echte Entscheidung steckt, wird das Tooling sehr schnell wertlos.

Findings als Datei

codeguard analyze . --output json --output-file findings.json

Damit könnt ihr Findings in eurem PR-System weiterverarbeiten, in Tickets mappen oder einen Trend tracken. Format-Details unter Output-Formate.