Visual Studio Code-Metriken Codezeilen Fehlmeldungen

Question

Der Code-Analysator Metriken in Visual Studio, sowie das Code-Metriken Elektrowerkzeug, um die Anzahl der Zeilen des Codes in den TestMethod Verfahren des folgenden Codes berichtet als 8.

allenfalls würde erwarten, dass ich es Zeilen Code melden als 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)); 
    } 
} 

Kann mir jemand erklären, warum dies der Fall ist?

Weitere Informationen

Nach etwas mehr graben die ich gefunden habe, dass die out Parameter aus dem Testverfahren zu entfernen und die Aktualisierung des Testcode verursacht LOC als 2 berichtet werden, was ich glaube, richtig ist. Die Hinzufügung von out verursacht den Sprung, also nicht wegen Klammern oder Attributen.

Dekompilieren der DLL mit dotPeek enthüllt eine Menge zusätzlichen Code generiert wegen der out Parameter, der 8 LOC berücksichtigt werden kann, aber das Entfernen der Parameter und Dekompilierung zeigt auch generierten Code, der als 5 LOC betrachtet werden kann, so ist es nicht einfach eine Frage von VS Compiler generierten Code zählen (was ich glaube nicht, dass es sowieso tun sollte).

Answer 1

Es gibt verschiedene Definitionen von "Codezeilen" (LOC). Jeder versucht, etwas Sinn zu machen, was ich für eine fast bedeutungslose Metrik halte. Zum Beispiel google von effektiven Codezeilen (eLOC).

Ich denke, dass VS das Attribut als Teil der Methodendeklaration enthält und versucht, eLOC durch das Zählen von Anweisungen und sogar Klammern zu geben. Eine Möglichkeit ist, dass 'm => m.Test (out str)' als eine Aussage gezählt wird.

Bedenken Sie:

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

und diese:

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

Eine Definition von LOC ist die Zeilen zu zählen, die keinen Code haben. Dies kann sogar Klammern enthalten. In solch einer extrem vereinfachten Definition variiert die Zählung enorm vom Codierungsstil.

eLOC versucht den Einfluss des Codestils zu reduzieren oder zu eliminieren. Zum Beispiel kann, wie im vorliegenden Fall, eine Deklaration als "Linie" gezählt werden. Es nicht rechtfertigen, nur erklären.

Bedenken Sie:

int varA = 0; 
varA = GetAValue(); 

und diese:

var varA = GetAValue(); 

Zwei Linien oder ein?

Es kommt alles darauf an, was die Absicht ist. Wenn Sie messen möchten, wie groß ein Monitor ist, dann verwenden Sie vielleicht ein einfaches LOC. Wenn es darum geht, Komplexität zu messen, ist es vielleicht besser, Code-Anweisungen zu zählen, wie z. B. eLOC.

Wenn Sie die Komplexität messen möchten, verwenden Sie eine Komplexitätsmetrik wie die zyklomatische Komplexität. Mach dir keine Sorgen darüber, wie VS LOC misst, denn ich denke, es ist sowieso eine nutzlose Metrik.

Answer 2

Mit dem Tool NDepend erhalten wir eine # Zeilen Code (LoC) von 2 für TestMethod(). (Haftungsausschluss Ich bin einer der Entwickler dieses Tools). Ich schrieb einen Artikel über How do you count your number of Lines Of Code (LOC) ?, die Licht auf was ist logisch LoC, und wie alle .NET LoC Zählwerkzeuge verlassen auf die PDB Sequenzpunkte Technologie.

Meine Schätzung zu diesem LoC-Wert von 8 von VS metric, ist, dass es die LoC der durch den Lambda-Ausdruck generierten Methode enthält + es enthält die PDB-Sequenzen Punkte mit offenen/endenden Klammern (was NDepend nicht tut)). Auch eine Menge Gymnastik wird vom Compiler gemacht, um das zu tun, was str genannt wird, aber das sollte nicht das #LoC beeinflussen, das von den PDB-Sequenzpunkten abgeleitet wird.

Btw, schrieb ich zwei andere LoC Artikeln:

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