Bielu.StaticCode.Analyzers 1.0.0-beta.639111005801575032

Bielu.StaticCode.Analyzers

Roslyn-based static code analyzers that enforce coding conventions used across the bielu ecosystem.

Installation

<PackageReference Include="Bielu.StaticCode.Analyzers">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

Analyzers

BIELU001 – Decorator Naming Convention

Decorator classes must follow the naming pattern {Modifier}{InterfaceName}Decorator.

A class is considered a decorator when it:

1. Implements an interface that starts with I (e.g. IApiService)
2. Has a constructor parameter of the same interface type

The class name must end with {InterfaceNameWithoutI}Decorator (e.g. ApiServiceDecorator), optionally prefixed by a modifier (e.g. Cached, Logged, Resilient).

BIELU002 – Use Primary Constructor

Classes with a single constructor whose body only contains simple field or property assignments should use the primary constructor syntax introduced in C# 12.

// ❌ Traditional constructor - can be simplified
public class MyService
{
    private readonly ILogger _logger;
    public MyService(ILogger logger) { _logger = logger; }
}

// ✅ Primary constructor
public class MyService(ILogger logger)
{
    private readonly ILogger _logger = logger;
}

Conditions under which the rule does not apply:

• The class already uses a primary constructor
• The class is abstract or static
• The class has more than one constructor
• The constructor chains to another constructor (base(...) / this(...))
• The constructor body contains logic beyond simple assignments

BIELU003 – Use IOptionsMonitor<T>

Options should be injected using IOptionsMonitor<T> rather than IOptions<T> or IOptionsSnapshot<T>.

IOptionsMonitor<T> provides the current configuration value and supports change notifications, making it the preferred choice for hot-reload scenarios.

A code fix is provided to automatically replace IOptions<T> / IOptionsSnapshot<T> with IOptionsMonitor<T>.

BIELU004 – Use ILogger<T>

Constructor parameters should use the typed ILogger<T> (where T is the containing class) instead of the untyped ILogger interface. Typed loggers enable proper log categorization and filtering.

// ❌ Untyped logger
public class MyService(ILogger logger) { }

// ✅ Typed logger
public class MyService(ILogger<MyService> logger) { }

BIELU005 – Async Method Naming

Methods returning Task, Task<T>, ValueTask, or ValueTask<T> should have their name suffixed with Async.

// ❌ Missing Async suffix
public Task GetData() => Task.CompletedTask;

// ✅ Correct suffix
public Task GetDataAsync() => Task.CompletedTask;

Exceptions:

• Overridden methods (naming is dictated by the base class)
• Interface implementations (naming is dictated by the interface)
• Test methods (marked with [Fact], [Theory], [Test], or [TestMethod])

BIELU006 – IServiceCollection Extension Class Naming

Static classes containing extension methods on IServiceCollection should be named {Feature}ServiceCollectionExtensions.

// ❌ Wrong name
public static class MyFeatureExtensions
{
    public static IServiceCollection AddMyFeature(this IServiceCollection services) => services;
}

// ✅ Correct name
public static class MyFeatureServiceCollectionExtensions
{
    public static IServiceCollection AddMyFeature(this IServiceCollection services) => services;
}

BIELU007 – Use ArgumentNullException.ThrowIfNull()

Null guard clauses should use the modern ArgumentNullException.ThrowIfNull() pattern instead of manual if (param == null) throw new ArgumentNullException(...).

// ❌ Manual null check
if (name == null)
    throw new ArgumentNullException(nameof(name));

// ✅ Modern guard clause
ArgumentNullException.ThrowIfNull(name);

BIELU008 – Use ConfigureAwait(false)

In library code, awaited tasks should call .ConfigureAwait(false) to avoid capturing the synchronization context, preventing potential deadlocks and improving performance.

// ❌ Missing ConfigureAwait
await Task.Delay(100);

// ✅ Explicit ConfigureAwait
await Task.Delay(100).ConfigureAwait(false);

BIELU009 – Seal Internal Classes

Internal classes that are not designed for inheritance should be marked as sealed. This prevents accidental inheritance, makes intent clear, and enables JIT devirtualization optimizations. This rule is reported as Info severity.

// ⚠️ Could be sealed
internal class MyHelper { }

// ✅ Sealed
internal sealed class MyHelper { }

Exceptions:

• Classes that are already sealed, abstract, or static
• Classes with virtual or abstract members
• Classes that have derived classes in the same file

Contributing

See CONTRIBUTING.md for guidelines on contributing to this project.