Most software applications are developed by a team instead of by one person which can result in different coding standards being applied. Even with just a single developer, over time, the standards this developer uses can change. This can make working with a code-base confusing because similar things are implemented differently throughout the codebase.
Static Code Analysis (SCA) uses tooling to automatically examine code to find any issues with it. This can be used for more than just maintaining coding standards. It can also be used to ensure certain patterns are followed, and to prevent the use of insecure coding practices. SCA won’t be able to pick everything up, but it can be a major help in keeping a code-base consistent and of a high-quality.
StyleCop used to be the analyzer of choice for .NET applications, although recently, with the advent of Roslyn Analyzers and the .NET 5 SDK supporting Static Code Analysis directly, the .editorconfig file can be used without any extensions or NuGet packages needed. The severity level of any issue can be configured and can also be set to break the build if there is an issue. Individual issues can still be allowed by setting Attributes or compiler directives in the source code. The Microsoft documentation linked previously supplies a particularly good explanation of how to use this but does not supply a step-by-step walkthrough. I’ll provide that below, starting with a simple console application.
To start, create a new console application using the .NET 6 SDK (Anything greater than .NET 5 should work, but to follow along, .NET 6 would be the best choice).
The first step is to add an .editorconfig file to the solution. This will apply all the rules in the file to all projects in the solution. You can alternatively add the file at project level which will result in those rules only being applied at project level. In the Add New Item dialog box, you’ll see a choice for editorconfig File (.NET) and editorconfig File (default). The .NET file will create a file with the default .NET code style conventions. If you choose the default choice, it will create a blank .editorconfig file. I’ll be using the default file for this example.
As soon as you create this file, Visual Studio will open the editor for it. This will allow you to select assorted options and then save. There are various headings for several types of rules that you can configure – Whitespace, Severity and Naming Style. If you click on the Analyzers tab at the top, you will be able to configure available Roslyn Analyzers.
Find the Prefer braces section under Code Style and set Prefer braces to Yes and the Severity to Warning.
Then go back to the Program.cs file and add the following code:
if (currentDateTime.DayOfWeek == DayOfWeek.Saturday || currentDateTime.DayOfWeek == DayOfWeek.Sunday)
Console.WriteLine("It is the weekend!");
else
Console.WriteLine("It is a weekday!");
Now build the solution and look at the Warnings tab in the Error List. You will see two IDE0011 warnings to add braces to the if and else statement. Now go back to the editor config file and change the Severity to Error and try building again.
You will see that the build now fails, with errors being to Add braces to the if and else statements.
Now, change the code so that the braces are added and try to build again.
if (currentDateTime.DayOfWeek == DayOfWeek.Saturday || currentDateTime.DayOfWeek == DayOfWeek.Sunday)
if (currentDateTime.DayOfWeek == DayOfWeek.Saturday || currentDateTime.DayOfWeek == DayOfWeek.Sunday)
{
Console.WriteLine("It is the weekend!");
}
else
{
Console.WriteLine("It is a weekday!");
}
You’ll see that the build now passes.
In the Analyzers section of the .editorconfig file, you’ll see many other rules that can be enforced using Roslyn Analyzers. These will allow you to apply all sorts of analyzers such as security and performance analyzers when building your application. You can also configure these as Suggestions, Warnings or Errors (or disable them), just as you can for code styles.
The code for this post can be found here.