sonar-dotnet

Members and types should always have the lowest possible visibility.

Member Ordering:

1. Constants
2. Nested enum declarations
3. Fields
4. Abstract members
5. Properties
6. Constructors
7. Extension blocks
8. Methods
9. Nested types

Additional Ordering Rules:

• Within each category, order from highest to lowest accessibility (public, internal, protected, private).
• Place static fields and properties before instance ones.
• Place static methods after instance methods.
• Within a group, place methods that are called by other methods below their callers.

public int PublicMethod() => 42;

int CallerOne() => Leaf();

int CallerTwo() => Leaf() + PublicMethod();

int Leaf() =>  42;

Prefer methods over local functions by default. Use local functions only if they make the code significantly easier to understand, such as when:

• Accessing the method's local state directly (reducing parameter noise).
• The function name would not make sense at the class level.

Placement: Local functions must always be placed at the end of a method.

public int MethodWithLocalFunction(int x)
{
    return LocalFunction(x);
    
    int LocalFunction(int x) => x;
}

Use minimal and valuable names.

General Rules:

• Avoid 'Get' method prefixes. Use a true verb like Create or Find instead.
• Avoid generic words like Helper in class names.
• Avoid overwordy or complex names.

Lambdas and Variables:

• Single variable lambdas: use x.
• Multi-variable lambdas: use descriptive names, but x can be used for the main iterated item (e.g., (x, index) => ...).
• Roslyn callback context: use c.
• Short names for specific types: SyntaxTree tree, SemanticModel model, SyntaxNode node, and CancellationToken cancel.

PowerShell:

• All PowerShell names (parameters, variables, methods) must use PascalCasing.

Individual members must be separated by an empty line, except for the following sequences which should not be separated by empty lines:

• Sequence of constants
• Sequence of fields
• Single-line properties
• Abstract members

private const int ValueA = 42;
private const int ValueB = 24;

private int valueA;
private int valueB;

protected abstract int AbstractA { get; }
protected abstract void AbstractB();

public SemanticModel Model { get; }
public SyntaxNode Node { get; }

public int ComplexProperty
{
    get => 42;
    set
    {
        // ...
    }
}

public Constructor() { }

public void MethodA() =>
    MethodB();

public void MethodB()
{
    // ...
}

If you need rules not provided by Sonar, you can implement your own Roslyn analyzer.

• Standard Integration: All Roslyn-based issues are automatically picked up by the SonarScanner for .NET and pushed to SonarQube as external issues.
• Advanced Integration: To embed your custom analyzer directly into a SonarQube plugin (allowing you to manage rules from the SonarQube UI), use the SonarQube Roslyn SDK.

Rule unit tests in sonar-dotnet use special annotations within single-line comments to specify expected noncompliant code.

Supported comment tokens:

• C#: //
• VB.NET: '
• XML: <!--

These annotations allow you to define the primary location of an issue, secondary locations, expected issue messages, precise column offsets, and even compilation errors.

You can use the standalone Roslyn analyzers for C# and VB.NET by installing the corresponding NuGet packages. These packages provide static analysis for code quality and security directly within your development environment.

NuGet Packages:
- SonarAnalyzer.CSharp
- SonarAnalyzer.VisualBasic

If you encounter issues while using C# and VB.NET code analyzers, report them via the Community Forum.

Applicable products include:

• SonarQube cloud
• SonarQube server
• SonarQube for IDE (SonarLint)
• SonarAnalyzer.CSharp NuGet package
• SonarAnalyzer.VisualBasic NuGet package

When reporting, please include:

• Any exceptions thrown by the analyzer.
• Instances of False-Positive or False-Negative behavior.
• A minimal reproducible example for each case.