wizualne wskaźniki kod Studio błędnych wierszy kodu

Question

Analizator metryk kodu w Visual Studio, a także elektronarzędzia metryki kodu, Raport liczbę linii kodu w metodzie następującego kodu TestMethod jako 8.

Co najwyżej spodziewam się, że raportuje linie kodu jako 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)); 
    } 
} 

Czy ktoś może wyjaśnić, dlaczego tak się dzieje?

Więcej informacji

Po trochę więcej kopanie odkryłem, że usuwając parametr z metody badawczej out i aktualizację kodu testowego powoduje LOC być zgłaszane jako 2, która moim zdaniem jest prawidłowe. Dodanie out powoduje skok, więc nie jest to spowodowane aparatami ortodontycznymi lub atrybutami.

Dekompilacja biblioteki DLL za pomocą dotPeek ujawnia znaczną ilość dodatkowego kodu wygenerowanego z powodu parametru out, który można uznać za 8 LOC, ale usunięcie parametru i dekompilacja ujawni również wygenerowany kod, który można uznać za 5 LOC, więc nie jest to po prostu kwestia VS zliczająca wygenerowany przez kompilator kod (o którym nie wierzę, że powinien to zrobić).

Answer 1

Istnieje kilka typowych definicji "Lines Of Code" (LOC). Każdy stara się nadać sens temu, co uważam za prawie bez znaczenia metrykę. Na przykład google z efektywnymi liniami kodu (eLOC).

Myślę, że VS uwzględnia ten atrybut jako część deklaracji metody i stara się podać eLOC, licząc instrukcje, a nawet nawiasy klamrowe. Jedną z możliwości jest to, że "m => m.Test (out str)" jest liczony jako instrukcja.

Rozważ to:

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

a to:

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

Jedna z definicji LOC jest policzyć wiersze, które mają żadnego kodu. Może to nawet obejmować aparaty ortodontyczne. W tak ekstremalnie uproszczonej definicji liczba jest bardzo różna w zależności od stylu kodowania.

eLOC próbuje zmniejszyć lub wyeliminować wpływ stylu kodu. Na przykład, tak jak w tym przypadku, deklaracja może być liczona jako "linia". Nie usprawiedliwia, po prostu wyjaśnia.

Rozważ to:

int varA = 0; 
varA = GetAValue(); 

a to:

var varA = GetAValue(); 

dwa wiersze lub jeden?

Wszystko sprowadza się do celu. Jeśli chcesz zmierzyć, jak wysoki jest twój monitor, być może użyj prostej LOC. Jeśli celem jest zmierzenie złożoności, być może policzenie instrukcji kodu jest lepsze, na przykład eLOC.

Jeśli chcesz zmierzyć złożoność, użyj metryki złożoności, np. Złożoności cyklicznej. Nie przejmuj się tym, że VS mierzy LOC, ponieważ, jak sądzę, jest to bezużyteczna metryka.

Answer 2

Za pomocą narzędzia NDepend otrzymujemy # linie kodu (LoC) 2 dla TestMethod(). (Zastrzeżenie Jestem jednym z twórców tego narzędzia). Napisałem artykuł o How do you count your number of Lines Of Code (LOC) ? że rzuca światło na to, co jest logiczne LoC i jak wszystko NET liczenie LoC oprzyrządowanie polegać na sekwencji PDB wskazuje technologii.

Moje przypuszczenie dotyczące tej wartości LoC 8 dostarczonej przez metrykę VS polega na tym, że zawiera ona LoC metody generowanej przez wyrażenie lambda + zawiera ona punkty sekwencji PDB związane z klamrami otwierającymi/kończącymi (które NDepend nie). Również kompilator wykonuje wiele ćwiczeń, aby wykonać to, co nazywa się capturing the local variablestr, ale nie powinno to mieć wpływu na #LoC, który jest wywnioskowany z punktów sekwencji PDB.

Btw, pisałem 2 inne artykuły związane LOC

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