Static code analysis is a great tool for spotting some kinds of error in your code, for example, not disposing of objects that implement IDisposable. Also, it helps to enforce and validate if the code written is following a defined standard, for example, using PascalCase for class names and camelCase for parameter names. In this post I'll show how to use Roslyn Analyzers with C# to enforce some standards of code quality and code style on your code, throwing errors at compile time if any rules are not being respected and not allowing the code to be pushed to protected branches of the repository. This is part two in a three-part series on setting up a uniform formatting standard in your code editor. Read part 1 . here Roslyn Analyzers is the compiler platform for .NET. Roslyn Analyzers are static code analysis tools for Roslyn. They inspect your code for style, quality, maintainability, and practices that are likely to cause bugs. They work based on predefined rules that can have their severity configured in the file. Roslyn EditorConfig .NET 5 and later have the analyzers enabled by default. To enable them in earlier versions of .NET, you can set the property to on project files that uses a or install them as a nuget package: EnableNETAnalyzers true project SDK Setting EnableNETAnalyzers on the project file <PropertyGroup>
  <EnableNETAnalyzers>true</EnableNETAnalyzers>
</PropertyGroup> Installing as a nuget package Install-Package Microsoft.CodeAnalysis.NetAnalyzers Enabling more analyzers By default, only some rules are enabled, but we can configure this with the property in the project file: AnalysisMode <PropertyGroup>
  <AnalysisMode>Recommended</AnalysisMode>
</PropertyGroup> The property values allowed are different for .NET 6 and .NET 5 SDKs. Details . AnalysisMode here How to enable .NET Analyzers in VS Code .NET Analyzers work by default in Visual Studio, but they have to be enabled in VS Code. 1 - Navigate to . File > Preferences > Settings 2 - Navigate to or search for . Extensions > C# configuration omnisharp.enableRoslynAnalyzers 3 - Check the option. Omnisharp: Enable Roslyn Analyzers 4 - Navigate to or search for . Extensions > C# configuration omnisharp.enableEditorConfigSupport 5 - Check the option. Omnisharp: Enable Editor Config Support 6 - Restart C#/Omnisharp extension or VS Code. Types of rules .NET Analyzers have many categories of rules, but here I'll list just a few to explain how they interact with Visual Studio's features. : Default Editorconfig options, like indent size and tabs or spaces; Standard formatting : Language specific indentation, whitespaces, and wrapping. For instance, use spaces before parentheses in method definitions. Code Style - .NET Formatting : C# and Visual Basic specific rules. Examples: using instead of an explicit type, prefer auto properties instead of backing fields. Code Style - .NET Language var : Rules about the naming of code elements, like enforcing PascalCase for classes' names and Async at the end of async methods' names. Code Style - Naming Conventions : Rules for code that is unreachable or unused variables, fields, etc. Code Style - Unnecessary code : Rules to improve code quality. These rules help identify code that are likely to cause bugs or security problems. Examples: Do not declare static members on generic types, and Enums should have zero value. Code Quality The table below shows in which features of Visual Studio the fixes for these types of rules are applied on. Fixes applied on 🖹 Format 🧹 Code Cleanup 💡 Code Fix Standard Formatting ✔️ ✔️ ✔️ .NET Formatting ✔️ ✔️ ✔️ .NET Language ✔️ ✔️ Naming Conventions ✔️ Unnecessary Code ❗ ✔️ Code Quality ❗ ❗ Only some rules have fixes applied. 💡 In the , I explain how to configure Visual Studio to apply this rules on Code Cleanup and how to auto execute Code Cleanup on file save. previous post of this series Enforcing rules in our code Rules are configured in the EditorConfig file (that I explained in the of this series) and their severity can be defined in three levels. Conflicts in the rules are resolved in the following order: Part 1 Specific rules Category rules All analyzers rules In the example below, Naming rules violations ( ) will be considered , because it is defined for the specific rule: IDE1006 Warning # Defines that all analyzers rules are suggestions
dotnet_analyzer_diagnostic.severity = suggestion
# Defines that all Code Style analyzers rules are errors
dotnet_analyzer_diagnostic.category-Style.severity = error
# Defines that the rule IDE1006 is a warning
dotnet_diagnostic.IDE1006.severity = warning 1. Generate an EditorConfig file from Visual Studio First, we need to create an EditorConfig file with the configuration of the rules we will use as standards. Visual Studio has a tool to help you configure the rules of your EditorConfig file, showing a snippet of code of how the rules work. code style Go to Tools > Options > Text Editor > C# > Code Style; Configure your Code Style preferences in the General, Formatting and Naming sub-menus.
⚠️ Don't bother setting the severities here; some of them are only respected by Visual Studio and are not enforced on build and other IDEs; Back in the General sub-menu, click and save it in the folder your solution file is in ( ). Generate .editoconfig file from settings .sln ⚠️ If you are not using Visual Studio, you can use a sample and change it to your preferences, like the one from . Roslyn 2. Configure all projects to use the recommended .NET Analyzers Next, we set the AnalysisMode property in all our project files. For .NET 6 SDK and later, set it to or . Recommended All <PropertyGroup>
  <AnalysisMode>Recommended</AnalysisMode>
</PropertyGroup> 3. Set severity Error for all analyzers rules In our EditorConfig, include this line to set severity to for all rules. error # Set severity = error for all analyzers
dotnet_analyzer_diagnostic.severity = error 4. Correct the errors and override the severity for rules you don't want to use If you are enabling the analyzers in an existing project, many errors will be shown. Correct them and override their severity if they don't apply for you or you won't correct them at the moment. 💡 In the , I explain how to add fixers to Visual Studio's Code Cleanup. You can customize it to fix some rules violations. previous post of this series Setting rules severity directly in EditorConfig file # Other rules ...

# Set severity = none to the rules that are not important for me
dotnet_diagnostic.IDE0075.severity = none

# Set severity = warning to the rules that need to be resolved later
dotnet_diagnostic.IDE0047.severity = warning Setting rules severity from Visual Studio's Error List For errors showing up in the Error List, you can right click on the rule and click on . The severity configuration will be added to the EditorConfig file. Set severity > Choose a severity Setting rules severity from Visual Studio's Solution Explorer From Solution Explorer, open the node below your project, then right click on the rule and click on . The severity configuration will be added to the EditorConfig file. Dependencies > Analyzers Set severity > Choose a severity 5. Enforce the rules on build Enabling the analyzers only shows the messages in our IDE. To really enforce those rules, we have to inform the compiler to fail in case of rules violations, blocking changes that are not compliant to the standard to be merged into protected branches of the repository. To do this, we need to enable the property in all our project files. EnforceCodeStyleInBuild <PropertyGroup>
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
</PropertyGroup> Examples of rules being enforced Rules being enforced on Visual Studio Rules being enforced on VS Code Rules being enforced on dotnet build command Creating additional naming conventions Here are some naming conventions of the C# language: Symbols Convention Example class/record/struct PascalCase PhysicalAddress interface "I"+PascalCase IWorkerQueue public members PascalCase StartEventProcessing private/internal fields "_"+camelCase _workerQueue static fields "s_"+camelCase s_workerQueue local variables *️ camelCase isValid parameters camelCase name async methods PascalCase+"Async" GetStringAsync More details . here By default, Visual Studio doesn't create naming conventions for static fields, local variables, parameters and async methods. If we want to use them, we have to manually set those rules, as shown below. *️ Not specified in the docs, but . Roslyn uses this convention Creating the naming convention for async methods dotnet_naming_rule.async_methods_should_be_pascalcase_async.severity = error
dotnet_naming_rule.async_methods_should_be_pascalcase_async.symbols = async_methods
dotnet_naming_rule.async_methods_should_be_pascalcase_async.style = pascalcase_async

dotnet_naming_symbols.async_methods.applicable_kinds = method
dotnet_naming_symbols.async_methods.applicable_accessibilities = *
dotnet_naming_symbols.async_methods.required_modifiers = async

dotnet_naming_style.pascalcase_async.required_suffix = Async
dotnet_naming_style.pascalcase_async.capitalization = pascal_case Creating the naming convention for local variables and parameters dotnet_naming_rule.locals_and_parameters_should_be_pascal_case.severity = error
dotnet_naming_rule.locals_and_parameters_should_be_pascal_case.symbols = locals_and_parameters
dotnet_naming_rule.locals_and_parameters_should_be_pascal_case.style = camel_case

dotnet_naming_symbols.locals_and_parameters.applicable_kinds = parameter, local

dotnet_naming_style.camel_case.capitalization = camel_case How to ignore the CA1707 rule (Identifiers should not contain underscores) on test projects Some conventions for naming test methods use underscore. If that is your case, you will receive a violation for the CA1707 rule. To disable the rule only on the test project, create a file named in the root of your test project with the content below. GlobalSuppressions.cs using System.Diagnostics.CodeAnalysis;

[assembly: SuppressMessage("Naming", "CA1707:Identifiers should not contain underscores", Justification = "Not applicable for test names", Scope = "module")] Third-party analyzers There are third-party analyzers that can have additional rules that can be useful. These are some: Roslynator StyleCop Sonar Analyzer References and Links https://learn.microsoft.com/en-us/visualstudio/code-quality/install-net-analyzers?view=vs-2022 https://www.jetbrains.com/help/rider/Using_EditorConfig.html#export-code-style-settings https://marketplace.visualstudio.com/items?itemName=MadsKristensen.EditorConfig Liked this post? I post extra content in my personal blog. to see. Click here Also published . here

7 Ways You Can Use Git to Boost Productivity

Visit my blog

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Spotting and Preventing Formatting Errors in Your Code

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

7 Ways You Can Use Git to Boost Productivity

C# 8.0 Indices and Ranges

5 Tips to Improve Your Productivity in C# 8.0

7 things you didn’t know about .NET code

A Guide to Running ASP.NET Core & SQL Server from Docker

7 Ways You Can Use Git to Boost Productivity

C# 8.0 Indices and Ranges

5 Tips to Improve Your Productivity in C# 8.0

7 things you didn’t know about .NET code

A Guide to Running ASP.NET Core & SQL Server from Docker

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps