Blazor.Common.Analyzers 2.1.0

<br> <a href="https://github.com/glennawatson/RoslynCommonAnalyzers"> <img width="160" height="160" src="https://raw.githubusercontent.com/glennawatson/RoslynCommonAnalyzers/main/icons/icon.png" alt="Blazor.Common.Analyzers"> </a> <br>

Blazor.Common.Analyzers

A small set of Roslyn analyzers and code fixes that enforce one readability convention everywhere it can apply: a comma-delimited list — method/constructor parameters, call/new arguments, attribute arguments, primary-constructor parameters, generic type-parameter and type-argument lists, function-pointer parameter lists, and more — must either sit entirely on one line or have each item on its own line. A "jagged" layout (some items sharing a line, others wrapped) is reported, and the accompanying code fix rewrites the list so every item is on its own line.

// 👎 jagged — flagged
void Configure(string host, int port,
    bool useTls);

// 👍 each parameter on its own line
void Configure(
    string host,
    int port,
    bool useTls);

// 👍 all on one line
void Configure(string host, int port, bool useTls);

The analyzers target netstandard2.0, have no runtime dependencies, ship as a development-only NuGet package, and are built against the Roslyn that ships with Visual Studio 2022 17.14 (Microsoft.CodeAnalysis.* 4.14.0). The package id is Blazor.Common.Analyzers; the repository is RoslynCommonAnalyzers.

Diagnostics share the RCGS prefix. Every rule is category Readability, default severity Warning, and ships with a code fix.

Table of contents

• Installation
• Rules
• Configuring severity
• How it works
• Building and testing
• Contributing
• License

Installation

dotnet add package Blazor.Common.Analyzers

It is a DevelopmentDependency analyzer package — it adds no assemblies to your output and is not transitive to consumers of your library.

Rules

Each rule has a documentation page under docs/rules; the helpLinkUri on every diagnostic points there.

Configuring severity

These are formatting/readability conventions, so tune them per project in .editorconfig:

# bump everything to a build error
dotnet_diagnostic.RCGS0001.severity = error
# … or turn one rule off
dotnet_diagnostic.RCGS0007.severity = none

Prefer .editorconfig over scattering #pragma warning disable / [SuppressMessage].

How it works

Every rule is a SyntaxNodeAnalysisContext-based DiagnosticAnalyzer registered for a specific SyntaxKind (or two — e.g. RecordDeclaration + RecordStructDeclaration). It pulls the relevant SeparatedSyntaxList, and reports when the items are split across lines such that they are neither all on one line nor all on separate lines. The code fix rebuilds the list with a newline after the opening token and each separator (and re-indents one level deeper than the owning declaration), via the shared helpers in ArgumentsOrParameterOnSameLineHelper and UniqueLineCodeFixerHelper.

The solution follows the standard analyzer layout:

Building and testing

dotnet restore Blazor.Common.Analyzers.sln
dotnet build Blazor.Common.Analyzers.sln --configuration Release
dotnet test --solution Blazor.Common.Analyzers.sln --configuration Release

TreatWarningsAsErrors is on and the repo's .editorconfig is strict — the build is clean only when every analyzer (StyleCop, Roslynator, SonarAnalyzer, the .NET analyzers) is satisfied. Fix issues rather than suppressing them.

Contributing

Issues and PRs welcome. Adding a rule means: a Rcgs####…Analyzer.cs, a matching …CodeFixProvider.cs, a Rcgs####…AnalyzersUnitTest.cs (markup-based CSharpCodeFixVerifier tests), a docs/rules/RCGS####.md page, and a row in AnalyzerReleases.Unshipped.md.

License

MIT — see LICENSE.