Fixing your first finding

CodeCharter reports a finding. What now? Three responses are possible: fix it, deliberately suppress it, or disable the rule if it does not fit your team.

Reading a finding

Example output:

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.

This tells you:

• File and line: PricingEngine.cs:42
• Severity: warn
• Rule name: DateTime-Direct-Usage (this is the slug, searchable in the wiki)
• Description and recommendation directly below

Option A: fix it

Before:

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

After:

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);
}

On the next codecharter analyze run the finding is gone.

Option B: deliberately suppress it

Sometimes you have a good reason not to follow the rule at a particular location — for example in a migration class that is historical and should not be touched.

Inline suppression directly in the code:

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

The disable directive applies to the next line. For multiple lines:

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

More details under Suppressions.

Option C: disable the rule

If you do not want a built-in rule in your entire repo, disable it in your .codecharter configuration:

[disable]
DateTime-Direct-Usage

Only do this if the rule genuinely does not fit your team, not to avoid a single location. For a specific location, inline suppression is the right choice.

Order of response

Rule of thumb:

1. First consider whether the finding is correct. If it conflicts with your explicit architecture decision, the rule is wrong for you. Then use option C.
2. If the rule is correct but the location is a genuine exception: option B with a reason in the comment.
3. Otherwise: option A. If you have to silence a finding without a real decision behind it, the tooling quickly becomes worthless.

Findings as a file

codecharter analyze . --output json --output-file findings.json

This lets you process findings further in your PR system, map them to tickets, or track a trend. Format details under Output formats.