Using Microsoft Visual Studio code metrics for better code quality

Writing code that is easy to understand and maintain is important. Using code measuring tools makes this a whole lot easier. Microsoft’s IDE Visual Studio contains useful code quality analysis tools that can be easily enabled. This guide tells you how to get started.

Microsoft code analysis tool

The .NET platform created by Microsoft is one of the most popular development platforms. Most developers who use this platform, use C# as main language (supported by all modern technologies such as html, css and javascript) and use Visual Studio as development environment. It is a very user friendly environment. Because developers are used to work mostly in this environment, tools that work inside this environment are easiest to use.

Luckily Microsoft has integrated code analysis in Visual Studio. The tool is however somewhat hidden among the many options of Visual Studio, which is why we describe how to use it in this blog post. The analysis tool (it does not have any fancy name) inherits functionality from prior tools like FxCop and StyleCop, but the functionality has now been integrated into the IDE and functions straight out-of-the-box. It works for most types of code that can be developed with Visual Studio:  .NET managed code, native code (C/C++) and database applications. The focus of the tools is on all types of quality issues issues: design problems, non-secure data access, and coding style violations.

Running code analysis

The easiest approach to use this built-in code analysis, is to analyse the code using the default analysis settings. If your application can successfully compile, all you have to do to analyse the code using the default settings, is to open the project under Visual Studio, and select Analyze -> Run Code Analysis -> On Solution.

Configuring code analysis

You are able to fine-tune the Code Analysis, by selecting which rules are used to detect issues in the source code. You can either select a pre-defined set of source code rules that have been set-up by Microsoft or create a set of rules yourself. The full list of about 15 available rule sets can be found in the MSDN code analysis rule set reference. We recommend the Managed Recommended Rules rule set for managed code for most projects, since it is focused on rules that point to serious issues. For large existing projects that are only maintained, the number of warnings using this ruleset can be high. If you do not have time to immediately investigate and fix all findings, you can also start with the Managed Minimun Rules rule set for managed code.

To select a pre-defined set of source code rules, you have to follow the following steps: go to Analyze -> Configure Code Analysis -> For Solution. (Please be aware that you are not able to change the code analysis settings when Visual Studio is compiling or analysing your code). Once you are in the Configure Code Analysis screen, you can select a Rule Set for each project in your Solution.

If you have a paid version of Visual Studio (i.e. Professional, Premium or Ultimate) you can also choose to define your own Rule Set. In such a custom Rule Set, you can pick and choose which rules to activate. Defining your own Rule Set can be done as follows: go to File -> New -> File… and then select Code Analysis Rule Set. Once you have selected this option, you can select each individual rule to be included in your custom rule set. To ease the selection process we advise you to start with the rules that are included in a default Rule Set of Microsoft and then adjust this rule set based on your needs.

Example coding rules in Visual Studio

Code analysis tools are good at catching some issues but not good at catching others. They can be compared to a spell checker: clear spelling mistakes are easily spotted, but grammatical errors are often not caught by tooling. To get an understanding of what the tools can and cannot do for you, one must look at the individual rools. We have found the following rules very valuable, because they spot issues that commonly occur and are worth fixing:

• CA1031: Do not catch general exception types
• CA1051: Do not declare visible instance fields
• CA1061: Do not hide base class methods
• CA1062: Validate arguments of public methods
• CA1501: Avoid excessive inheritance
• CA1502: Avoid excessive complexity
• CA1506: Avoid excessive class coupling
• CA1811: Avoid uncalled private code
• CA2100: Review SQL queries for security vulnerabilities

If your team or company has a coding standard document, it probably has rules similar to these rules and the tool does not introduce new rules but simply helps developers adhere to the already agreed standard. Descriptions of all the rules can again be found online at MSDN under code analysis warnings.

Further reading

If you would like to know more about source code analysis in the Visual Studio environment, you can read the excellent guide on MSDN: Analyzing Application Quality by Using Code Analysis Tools. For those who are brave enough that want to program their own custom rules, we recommend that you start by reading Ralf Johnson’s Create custom code analysis rules in Visual Studio 2013. This is not recommended for beginners! For teams that do not have agreed coding standards or practices, we provide workshops where we explain which best practices are and how available tools can best be used. Contact us for more information.