SKU: Premium, Ultimate
Versions: 2008, 2010
[updated 5/15/2011: NASA has apparently removed the paper mentioned in this tip so I have added a new link]
In vstipTool0129, “Code Metrics – Calculating Metrics,” I showed you how to obtain code metrics. Getting the data is only half the battle. You have to know how to interpret the information. Here is an example of code metrics results:
Let’s take a closer look at Lines Of Code. According to the documentation, Lines of Code:
“Indicates the approximate number of lines in the code. The count is based on the IL code and is therefore not the exact number of lines in the source code file. A very high count might indicate that a type or method is trying to do too much work and should be split up. It might also indicate that the type or method might be hard to maintain.”
Additionally, per the documentation, there are some caveats to the calculations you need to consider:
Code metrics, for the most part, ignores generated code since the majority of that code typically can’t be modified by the developer directly.
“Metrics results for an anonymous method that is declared in a member, such as a method or accessor, are associated with the member that declares the method. They are not associated with the member that calls the method.”
Although the documentation only mentions anonymous methods, it is safe to assume the information applies to lambda expressions as well.
Lines of Code as a Metric
Strictly speaking, lines of code as a metric on its own is usually not the best predictor of code quality. According to the Software Assurance Technology Center (SATC) at NASA:
“Size is one of the oldest and most common forms of software measurement. Size of modules is itself a quality indicator. Size can be measured by: total lines of code, counting all lines; non-comment non-blank which decreases total lines by the number of blanks and comments; and executable statements as defined by a language dependent delimiter.
The SATC has found the most effective evaluation is a combination of size and [Cyclomatic] complexity. The modules with both a high complexity and a large size tend to have the lowest reliability. Modules with low size and high complexity are also a reliability risk because they tend to be very terse code, which is difficult to change or modify.
Although these metrics are also applicable to object oriented code, additional metrics are needed to evaluate the quality of the object oriented structure. The SATC uses the following metrics for object oriented quality analysis: Weighted methods per class (WMC), Response for a Class (RFC), [Class Coupling], Depth in [Inheritance] Tree (DIT), and Number of Children (NOC).”
Putting It All Together
When using code metrics in Visual Studio we can logically assume that lines of code is a broad predictor for software quality; however it is best used in conjunction with other metrics for a more accurate analysis.