How to interpret received metrics results?

Okay; let´s face it… calculating numbers is one thing. Getting a feeling for what the numbers are telling us is another one. The power tool calculates five metrics; the maintainability index, cyclomatic complexity, depth of inheritance, class coupling and lines of code. But what do the numbers really mean? Well, I would say there is no unique answer to that question. But there is a very good description about the interpretation of the results at Vitaly´s WebLog. Seems that the mentioned blog post is no longer available; so I´ll try to shed some light…

Lines of Code

Let´s start with one of the most controversial metrics (in my opinion): the (effective) lines of code metric. This metric is calculated on method level and depends on the IL code that is generated by the compiler. Sometimes it might happen that you just wonder yourself about that number, and you may have the feeling that the metric result is wrong. Indeed, the result might slightly differ from what you´ve actually written in source-code, or what the individual developer would treat as an effective line of code (for instance, comments are not counted by this metric). Anyway, those slight differences don´t matter… this method can be used as an indicator for methods, which are huge (having more than 20 lines of code), because in most cases huge methods often tend to fulfil multiple purposes, or satisfy different concerns which make it hard to apply changes or provide tests. Code Metrics Viewer rates this metric value the following way: 1-10 lines are good (green), 11-20 lines are still okay (yellow), everything above 20 lines is critical (red) and should be reviewed and possibly refactored into smaller functions.

Class Coupling

This metric can be used as an indicator of how evolvable a function, a class, or at least an assembly project actually is. It is calculated for each level and represents the number of types (except built-in language types) beeing used by a method, class, etc.. Lower values are better. Code Metrics Viewer rates this metric value the following way: 0-9 dependencies is good (green), 10-30 dependencies (on member level) and 10-80 dependencies (on type level) are still okay (yellow), more than 30 dependencies (on member level) and more than 80 dependencies (on type level) are critical (red) and should be reviewed and possibly refactored.

Depth of Inheritance

The depth of inheritance metric indicates the number of types within the inheritance chain (the total number of base classes). Lower values are better because the more there are the tougher it could be to follow the flow of the code when debugging or analyzing. Code Metrics Viewer rates the metric value the following way: 1-2 base types are good (green), 3-4 base types are still okay (yellow), everything above 4 is critical (red) and should be reviewed and possibly refactored.

Cyclomatic Complexity

This metric is calculated on method level and indicates the total number of independent branches of the method´s control-flow graph. The value increases by the number of logical expressions which can change the control flow (if, switch/case, for- and while-loop statements). A method that does not contain any control-flow statements has a cyclomatic complexity of one, which means there´s only a single branch. Code Metrics Viewer rates the metric value the following way: 1-10 branches are good (green), 11-20 branches are still okay (yellow), more than 20 branches is critical (red) and should be reviewed and possibly refactored. The cyclomatic complexity metric is quite important because it can be seen as “the minimum number of tests required”, in order to cover all branches… on the other hand, it can be used to unveil code that is hard (or impossible) to test.

Maintainability Index

The maintainability index metric can be used as an overall quality indicator even if not all of the other provided metrics are taken into account to calculate that metric result. Actually, only the cyclomatic complexity and lines of code metric results are used directly – and some other metric values that are not exposed by the Code Metrics Power Tool. Those “hidden” values are called Halstead complexity measures, whereby only the Halstead volume is used for the calculation of the maintainability index (of course, the class coupling has an impact on the Halstead volume, as well as used operators and operands). Result values are between 0 and 100, whereby larger values indicate a higher (better) maintainability. The Code Metrics Viewer rates the metric value the following way: 100-20 is good (green), 19-10 is still okay (yellow), 9-0 is critical (red), but I usually review everything that has a lower value than 50.


How to get results for code behind XAML-files

In June, a user reported a problem where he does not see any results for code behind XAML files. I dove into the problem and figured out that code behind XAML files was handled by the power tool like generated code, which I had disabled by default using the /igc switch. The latest version of the tool allows to take control over the switch; if you want to calculate code metrics for generated code you have to make sure, that the /igc option is disabled.

How can I calculate code metrics?

After a solution was loaded and successfully build, it can be analyzed by pressing the “Analyze Solution” button. The Code Metrics Viewer will utilize the power tool to create the code metric report for each assembly in the solution. Depending on the solution size, this can take a while… The results will be shown in the grid.

How to get it working?

Before you can use Code Metrics Viewer within Visual Studio 2010, you also need to download and install Code Metrics Power Tool 10.0. The Code Metrics Power Tool 10.0 is a console application which is available at Microsoft. The download can be found at

The extension comes up with its own options page, where you can specify the installation path of the Code Metrics Power Tool. Please have a look at the Readme-file provided together with the Code Metrics Power Tool 10.0 to find out the installation folder (might be: <Program Files>\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop). The specified path shall not contain a filename (the extension will add the name of the executable). Consider that there is a difference in the <Program Files> path between 32- and 64-bit versions of Windows.

What is Code Metrics Viewer?

Well, Code Metrics Viewer is an extension for Visual Studio 2010 Professional, which integrates the Code Metrics Power Tool 10.0 into the development enviroment. I came up with this utility in March this year; since that the tool was downloaded 2.700+ times and I got a lot of positive feedback from developers. I was also very happy about the fact, that the tool was mentioned by an article in Microsoft´s Visual Studio Magazine: 17 free tools for Visual Studio. Actually, I am planning to publish a new release containing a bunch of new features in the end of this summer. By now, the description page of the tool at the Visual Studio Gallery is getting longer and longer, so it´s not very user-friendly anymore. To get rid of this problem, I will use this blog to bring all the information to you…

The Code Metrics Viewer is completly free; the download can be found here: