Code Metrics is a new feature that has been introduced in upcoming Visual Studio 2008 (Orcas). There are 5 code metrics available - Lines of Code, Class Coupling, Depth of Inheritance, Cyclomatic Complexity, and Maintainability Index.

There is good description how metrics are calculated on Code Analysis Team Blog. However, they miss info on how to interpret received numbers. I will try to provide some additional details below. I will also provide numbers you may want to keep metrics in your typical project in.

Lines of Code

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates)

This one is simple one. This metric is most famous for its misuse. So use it carefully, ideally for information only, to see how large the class or method is.

Do NOT use it to:

• Measure programming progress of the project. There is not only coding.
• Measure Productivity of developer. The same functionality can be developer with a different amount of code and the goal of every developer is to develop functionality, not to just write. Some code can be generated and someone can just copy and paste code.
• Estimate a project. Because of above written.

Class Coupling

Class coupling is a class-level metric (as it may be inferred from its name). It counts number of classes class X depends on (distinct non-inheritance related classes). The rule of thumb here is that the less this metric for a class, the more stable it is. Stable class does not break on changes in other classes and does not require changes when other classes are changed. The more stable class is, the more it deserves to be a class to reuse.

Ideally, try to avoid highly coupled classes. It seems that threshold value 30-40 indicates a potentially bad design for a typical project (I'm not sure on this number; please correct me if I wrong).

Carefully use coupling number that is presented for an assembly. I'm not sure why they provide it. For me it seems senseless without number of classes in assembly.

It's a pity that Visual Studio does not show the number of classes in other assemblies that a class depends on. Ideally, there should be ratio like {Number of All Dependant Classes}/{Number of Dependant Classes in other Assemblies}.

Depth of Inheritance

This metric is also quite simple. It indicates the number of base classes (i.e. number of classes between class X and System.Object +1). It is recommended to keep this metric in a value not higher than 6. Higher value may mean that system is hard to maintain and that a risk of a breaking change is high.

Cyclomatic Complexity

This is a method-level metric. It shows the number of linearly independent paths code can execute. The more if, switch, while, do and other such statements you have the higher this number is. Try to keep it less than 20 for a method. Higher value indicates complicated and hardly maintainable code. A method with a low cyclomatic complexity is generally better.

This metric also usable to see how many tests you need to write to cover all your code.

Maintainability Index

This is a magic number showing how good your code is. It is calculated from several metrics and proven to be quite effective. It varies between 0 and 100. Although all metrics above are better when low, this one is opposite, the higher its value, the better your code is.

If you curious to see how this metric is calculated here is the formula that seems to be used to calculate MI in VS. The last part is strikethrough because it seems they not count comments.

MI = 171 - 5.2 * ln(aveV) - 0.23 * aveV(g') - 16.2 * ln (aveLOC) + 50 * sin (sqrt(2.4 * perCM))
The coefficients are derived from actual usage. The terms are defined as follows:
aveV = average Halstead Volume V per module
aveV(g') = average extended cyclomatic complexity per module
aveLOC = the average count of lines of code (LOC) per module; and, optionally
perCM = average percent of lines of comments per module

Visual Studio will tell you that your code is highly maintainable if MI is between 20 and 100 inclusive. I would raise the lower bar to 50 or even higher.

Generated code

You may want to skip generated code from code analysis. It can be done by using the following attributes:

• Compiler Generated. Does not display or generate metrics for code marked with the CompilerGeneratedAttribute. Also users an algorithm to determine if other code is compiler generated.
• Tool Generated. Does not display or generate metrics for code marked with the GeneratedCodeAttribute.

Conclusion

It is good to have this new feature in Visual Studio. It helps to see the quality of code at a glance. You see problematic places into which you can easily drill down to see details. It is also easy to create new Work Item from the same window. There are not too many metric types, although they seem to be enough for mostly uses. Those who want more metric types and not afraid to drown in numbers may use NDepend.

The main disadvantage is UI of this new feature that confusing sometimes. Method level metrics are mixed with class level and shown even for assemblies. This presentation of metric values may be quite confusing and misleading for a beginner. It would be better to hide values when they are not relevant or add additional info (like number of classes for class coupling on assembly level).

PS

Code that does not exist is counted. And it has not good MI (that probably affects MI for a class and assembly)

Do not write too much code. You code won't be better from that… Good example of LOC metric misuse :-)