Code Quality Assessment Tool in MS Visual Studio

Introduction

Quite often, programmers have to maintain someone else's code, very often this code does not look the best, and it is very difficult to accompany it. If this application does not have to be thrown out soon, then naturally it is worth bringing it into a human form, i.e. to refactor. It would be good to have some metric that would allow to evaluate the quality of the code and determine the places that should be improved. Such a metric would allow to evaluate, for example, how the programmer writes the source code or how good the code is in the application that you are going to support.

Microsoft provides built-in Visual Studio tool that allows you to evaluate the code of your project.


')
You can get an estimate of your code by right-clicking on the project and selecting the “Calculate Code Metrics” item (This functionality is available in Visual Studio 2008 Team System and Visual Studio 2010 from the Premium version).

Metrics description

The results contain 5 metrics for your code.

1. Maintainability Index is a comprehensive indicator of code quality. This indicator was developed by experts from the Carnegie Mellon Software Engineering Institute. The metric is calculated using the following formula:
   
   MI = MAX (0, (171 - 5.2 * ln (HV) - 0.23 * CC - 16.2 * ln (LoC)) * 100/171)
   
   
   • HV - Halstead Volume, computational complexity. The more operators, the greater the value of this metric;
   • CC - Cyclomatic Complexity. This metric is described below;
   • LoC - the number of lines of code.
   
   This metric can take values ​​from 0 to 100 and shows the relative difficulty of supporting the code. The greater the value of this metric, the easier it is to maintain the code.
   
   Visual Studio marks methods / classes in green if the value of the metric is in the range from 20 to 100, in yellow in the case when the value is in the range from 10 to 20, and in red when the value is less than 10.
2. Cyclomatic Complexity - shows the structural complexity of the code, i.e. the number of different branches in the code. The larger this indicator, the more tests must be written to fully cover the code.
3. Depth of Inheritance - the depth of inheritance. For each class, this metric shows what it counts in the inheritance chain. For example, there are 3 classes A, B, C, B inherited from A, and C inherited from B, then the value of this metric for classes A, B and C will be equal to 1, 2 and 3, respectively.
4. Class Coupling - shows the degree of dependence of classes with each other. They take into account unique classes from parameters, local variables, return type, base class, attributes (the full list can be found in MSDN ). Good software design involves a small number of related classes. The more of them, the more difficult it is to reuse this class in the future, and also to support, because There are so many dependencies.
5. Lines of Code - shows the number of lines of code. This indicator does not show the exact number of lines in your file, because counting is based on IL code. Empty lines, comments, lines with brackets, type and namespace declarations are not taken into account. A large number of lines in a method / class may indicate errors in design and that this code can be divided into several parts.
   

More details about how these metrics are considered can be found here .

Real use

When I first launched the analysis on one of the projects, all the values ​​of the Maintainability Index were green. It seemed a bit strange because there was clearly code to rewrite. The MI values ​​for such code sections were about 30-40. It turns out that the default indicators are most likely subjective, and the decision on what code to consider as low-quality will have to be taken by the programmers themselves.

For my projects, I try for most methods to maintain an MI of around 70-90. There are methods in which this indicator is 50-60, and they can be rewritten, but it is worth evaluating the costs and benefits.

Thanks to this tool, you can quite easily conduct a code review of a large project, find places that need to be rewritten. It is also quite useful to follow the process of changing the above metrics. This can show the manager about the attitude of programmers to the development of a project, as well as the dynamics of code quality change for each programmer, which is important in our profession. Another reason for tracking metrics is that the programmer-defined threshold values, upon reaching which, need to do refactoring.

Thank you very much.

Sources

1. MSDN
2. PC Week
3. Code Analysis Team Blog