Visual Studio code metrics misreporting lines of code

Question

The code metrics analyser in Visual Studio, as well as the code metrics power tool, report the number of lines of code in the TestMethod method of the following code as 8.

At the most, I would expect it to report lines of code as 3.

[TestClass]
public class UnitTest1
{
    private void Test(out string str)
    {
        str = null;
    }

    [TestMethod]
    public void TestMethod()
    {
        var mock = new Mock<UnitTest1>();

        string str;
        mock.Verify(m => m.Test(out str));
    }
}

Can anyone explain why this is the case?

Further info

After a little more digging I've found that removing the out parameter from the Test method and updating the test code causes LOC to be reported as 2, which I believe is correct. The addition of out causes the jump, so it's not because of braces or attributes.

Decompiling the DLL with dotPeek reveals a fair amount of additional code generated because of the out parameter which could be considered 8 LOC, but removing the parameter and decompiling also reveals generated code, which could be considered 5 LOC, so it's not simply a matter of VS counting compiler generated code (which I don't believe it should do anyway).

Answer 1

There are several common definitions of 'Lines Of Code' (LOC). Each tries to bring some sense to what I think of as an almost meaningless metric. For example google of effective lines of code (eLOC).

I think that VS is including the attribute as part of the method declaration and is trying to give eLOC by counting statements and even braces. One possiblity is that 'm => m.Test(out str)' is being counted as a statement.

Consider this:

if (a > 1 &&
    b > 2)
{
   var result;
   result = GetAValue();
   return result;
}

and this:

if (a> 1 && b >2)
   return GetAValue();

One definition of LOC is to count the lines that have any code. This may even include braces. In such an extreme simplistic definition the count varies hugely on coding style.

eLOC tries to reduce or eliminate the influence of code style. For example, as may the case here, a declaration may be counted as a 'line'. Not justifying it, just explaining.

Consider this:

int varA = 0;
varA = GetAValue();

and this:

var varA = GetAValue();

Two lines or one?

It all comes down to what is the intent. If it is to measure how tall a monitor you need then perhaps use a simple LOC. If the intent is to measure complexity then perhaps counting code statements is better such as eLOC.

If you want to measure complexity then use a complexity metric like cyclomatic complexity. Don't worry about how VS is measuring LOC as, i think, it is a useless metric anyway.

Answer 2

With the tool NDepend we get a # Lines of Code (LoC) of 2 for TestMethod(). (Disclaimer I am one of the developers of this tool). I wrote an article about How do you count your number of Lines Of Code (LOC) ? that is shedding light on what is logical LoC, and how all .NET LoC counting tooling rely on the PDB sequence points technology.

My guess concerning this LoC value of 8 provided by VS metric, is that it includes the LoC of the method generated by the lambda expression + it includes the PDB sequences points related to open/ending braces (which NDepend doesn't). Also lot of gymnastic is done by the compiler to do what is called capturing the local variable str, but this shouldn't impact the #LoC that is inferred from the PDB sequence points.

Btw, I wrote 2 others related LoC articles:

• Why is it useful to count the number of Lines Of Code (LOC) ?
• Mythical man month : 10 lines per developer day