Jaki jest cel analizy kodu i kiedy muszę go używać?

Słyszałem o analizie kodu Visual Studio, ale nigdy jej nie użyłem. Przeczytałem MSDN , ale nadal nie rozumiem prawdziwego zastosowania analizy kodu.

Czy to nie to samo co StyleCop?

Gdzieś wspomniano także o FxCop. Jaka jest różnica w analizie kodu?

Czy muszę używać analizy kodu dla każdego projektu? Czy recenzje kodu wykonywane przez moich kolegów są niewystarczające?

Co to jest analiza kodu?

Analiza kodu (wcześniej FxCop) to narzędzie do analizy statycznej , które wyszukuje typowe wzorce, które mogą wskazywać, że coś jest nie tak z kodem źródłowym. Na przykład, jeśli instancja klasy, która implementuje IDisposablesię, nie jest poprawnie usuwana, analiza kodu wyświetli ostrzeżenie:

private void DoSomething()
{
    var connection = new SqlConnection(...);
    this.ChangeSomeData(connection);
}

To jest poprawna implementacja poprzedniego fragmentu kodu:

private void DoSomething()
{
    using (var connection = new SqlConnection(...))
    {
        this.ChangeSomeData(connection);
    }
}

Jak każde narzędzie do analizy statycznej, analiza kodu ma na celu znalezienie wzorców, które są kłopotliwe (lub po prostu nudne) do znalezienia ręcznie. Na przykład w poprzednim przykładzie sprawdzenie, czy jakaś klasa, której używa, jest dość nudne IDisposable(lub zapamiętanie wszystkich klas .NET Framework, które ją implementują).

Które projekty się kwalifikują?

Chociaż podlega on fałszywym trafieniom, jak każde narzędzie do analizy statycznej, zwykle korzystne jest kierowanie zerowych ostrzeżeń dla kodu o znaczeniu krytycznym dla biznesu bez stosowania eliminacji . W programie Visual Studio analizę kodu można skonfigurować do uruchamiania w czasie kompilacji; jeśli ustawienia projektu określają również, że ostrzeżenia powinny być traktowane jako błędy, naruszenia zasad analizy kodu nie pozostaną niezauważone.

Ponieważ analiza statyczna może zająć trochę czasu w przypadku średnich i dużych projektów, często dobrym pomysłem jest przeniesienie jej z komputerów programistów na serwer kompilacji TFS. Chociaż uruchamianie analizy kodu podczas zatwierdzenia wstępnego nie jest dobrym pomysłem (w przeciwieństwie do StyleCop), może ono nadal działać przy kompilacji i zawieść, jeśli zostaną znalezione ostrzeżenia.

W przypadku kodu niekrytycznego dla biznesu analizę kodu można uruchomić ręcznie z programu Visual Studio lub wiersza polecenia. Kontrole i ostrzeżenia mogą być drobnoziarniste we właściwościach projektu, aby dopasować je do twoich potrzeb. Na przykład ostrzeżenia o globalizacji można wyłączyć, jeśli projekt nie jest przeznaczony do lokalizacji.

Podobnie jak w przypadku StyleCop, ważne jest, aby zdecydować, czy projekt będzie kierował zero ostrzeżeń z analizy kodu od początku projektu. Wprowadzenie go do istniejącego projektu może być zbyt bolesne.

Czy różni się od StyleCop?

Zauważ, że analiza kodu to nie to samo, co StyleCop . Pierwszą różnicą jest to, że analiza kodu działa ze skompilowanym zestawem, podczas gdy StyleCop działa z samym źródłem. Druga (i najważniejsza) różnica polega na tym, że analiza kodu wyszukuje wzory, które mogą wskazywać na błąd, podczas gdy StyleCop po prostu egzekwuje reguły stylu - prosta konwencja stosowana przez zespół.

Analiza kodu jest szczególnie przydatna dla początkujących, którzy nie znają dobrze języka , ponieważ często może prowadzić do „Aha!” chwile. Na przykład CA2105: Pola tablicy nie powinny być tylko do odczytu, może doprowadzić do odkrycia, że ​​nawet jeśli tablica jest oznaczona jako tylko do odczytu, nie czyni jej niezmiennym, ponieważ nic nie zabrania zmiany elementów w tablicy. StyleCop nie prowadzi do odkryć: nie ma nic ciekawego w tym, że pola zaczynają się od małej litery lub że lokalne połączenia powinny być poprzedzone this.

Nawet jeśli niektóre reguły są egzekwowane zarówno przez analizę kodu, jak i StyleCop (takie jak CA1707: Identyfikatory nie powinny zawierać podkreślników vs. SA1310: Nazwy pól nie mogą zawierać podkreślników ), te dwa narzędzia są komplementarne i często używane obok siebie.

Mamy już recenzje kodu

Obecność recenzji kodu nie jest powodem do unikania analizy kodu. Zarówno analiza kodu, jak i StyleCop doskonale sprawdzają się automatycznie przed przeglądaniem kodu. Nie ma nic gorszego niż spędzanie przeglądu kodu, który wskazuje problemy ze stylem lub problematyczne wzorce, które można znaleźć automatycznie. Przechowuj recenzje kodu dla interesujących rzeczy.

Innym aspektem jest to, że ludzcy recenzenci niekoniecznie są dobrzy w wykrywaniu problemów wykrytych przez analizę kodu. Na przykład instancja klasy implementującej IDisposablemoże zostać utworzona w jednym miejscu, a następnie umieszczona w innym miejscu. Znalezienie go zajmie trochę czasu, a narzędzie analizy statycznej zajmie tylko kilka milisekund.