ReSharper and Static Analysis

Purpose

Static analysis reduces defects, improves maintainability and gives reviewers more time to focus on design rather than formatting and simple mistakes.

AIC uses a layered analysis model:

1. C# compiler diagnostics

2. .NET Roslyn analyzers

3. .editorconfig style rules

4. ReSharper inspections

5. security and dependency scanners

6. human code review

AIC Standard

• ReSharper SHOULD be used for C# development in Visual Studio.

• ReSharper settings SHOULD be committed or distributed through team settings where appropriate.

• ReSharper command-line tools SHOULD run in CI for repositories where ReSharper rules are part of the quality gate.

• Roslyn analyzers MUST run in build.

• Analyzer warnings MUST be visible and should be treated as errors for production code.

• Formatting MUST be automated through .editorconfig, dotnet format and/or ReSharper cleanup.

ReSharper Uses

AIC uses ReSharper for:

• code inspections

• refactoring

• navigation

• naming consistency

• dead code detection

• nullability improvements

• code cleanup

• formatting

• test runner integration

• solution-wide analysis

• command-line inspection reports

CI Command Examples

Example ReSharper InspectCode command:

jb inspectcode Aic.Project.sln --output=artifacts/resharper-inspections.xml --format=Xml

Example ReSharper CleanupCode command:

jb cleanupcode Aic.Project.sln --profile="AIC Full Cleanup"

Severity Model

Severity	Meaning	CI action
Error	Must fix before merge	Fail
Warning	Should fix before merge	Fail or require approval
Suggestion	Improve when touching code	Do not fail by default
Hint	Developer productivity	Do not fail

Mandatory Checks

Static analysis must check for:

• compiler errors

• nullable reference warnings

• unused code

• unreachable code

• incorrect async usage

• disposed object usage

• insecure APIs

• poor exception handling

• naming violations

• formatting violations

• package vulnerabilities

Suppression Rules

Suppressions are allowed only when:

• the rule is not applicable

• the warning is a false positive

• fixing creates disproportionate risk

• there is a documented technical constraint

Suppressions must be narrow. Do not suppress entire rule categories because of local inconvenience.

Use:

#pragma warning disable CAxxxx // Reason with ticket or ADR reference
#pragma warning restore CAxxxx

or .editorconfig only where team-wide suppression is justified.