Code Metrics – Lines of Code

SKU: Premium, Ultimate

Versions: 2008, 2010

Code: vstipTool0130


[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:

Generated Code

Code metrics, for the most part, ignores generated code since the majority of that code typically can’t be modified by the developer directly.


Anonymous Methods

“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.

Comments (2)
  1. Daniel says:

    "Code metrics, for the most part, ignores generated code since the majority of that code typically can’t be modified by the developer directly."

    It does not ignore generated code. The LoC in Visual Studio 2010 includes the InitializeComponent() method, which clearly states, "do not edit the contents of this method with the code editor."

    This rendered the Lines of Code metric nearly useless to me in my project that included many user controls. I was able to export the results to a spreadsheet and write an excel function which calculated the LoC without the InitializeComponent() method.

  2. zainnab says:

    Hey Daniel 🙂

    That is correct, which is why I said:

    "Code metrics, FOR THE MOST PART, ignores generated code since the majority of that code typically can’t be modified by the developer directly."

    as opposed to "Code metrics COMPLETELY ignores generated code […]"


Comments are closed.

Skip to main content