Otwieramy solucję, buildujemy projekt, czekamy chwilę i co widzimy?

Jak widać, wszystkie projekty się zbudowały. Chyba jest więc dobrze?

No i właśnie niekoniecznie. Budowanie się projektu to jedna sprawa. A lista warningów, które można naprawić – to osobna sprawa.

Co to jest FxCop?

Jest to narzędzie, które sprawdza poprawność naszego kodu z odgórnie ustalonym wzorcem Microsoftu (.NET Framework Design Guidelines). Wzorzec dotyczy m.in. nazewnictwa, bezpieczeństwa, czy wydajności.

Co ważne, analizuje on skompilowany kod, a nie kod źródłowy (dlatego po każdej zmianie należy przebudować projekt).

Jak zacząć z FxCop?

Dodajmy do każdego projektu paczkę FxCop:

W Dependencies powinniśmy zobaczyć katalog Analyzers z nowymi pozycjami:

Możemy również zobaczyć referencje w pliku *.csproj:

Co to jest StyleCop?

Jest to takie narzędzie, które ujednolica styl pisania w projekcie. Czyli między innymi wymaga określonych zasad pod względem formatowania, wcięć, spacji, nazewnictwa itp.

Jak zacząć ze StyleCop?

Pierwszy krok to dodanie do każdego projektu paczki StyleCop:

Widać nową referencję w pliku *.csproj:

Analiza kodu – warnings

Po przebudowaniu solucji widać, że mamy sporo warningów. Na początku bezpieczniej, żeby były to warningi. Wraz z upływem czasu i uporządkowaniem „starych śmieci” będzie można włączyć rozpoznawanie złamania zasad jako Errory.

Co można zrobić, gdy nie zgadzamy się z daną regułą i nie chcemy się do niej stosować? Można ją „stłumić” (suppress) – albo na poziomie konkretnej linijki kodu, albo w globalnym pliku GlobalSuppresions.cs. Wystarczy rozwinąć komunikat warningu i kliknąć prawym klawiszem myszy. Wtedy rozwinie się dodatkowe menu.

Dla mojej solucji preferuję odrębny plik z listą wyłączonych zasad.

Naprawianie błędów

Co należy zrobić, gdy chcemy się zastosować do danej reguły? Wystarczy podążać za żółtą żarówką. Podpowie, jakie jest rozwiązanie – nawet zademonstruje je na przykładzie. Rozwiązanie można zastosować jeden raz lub wiele razowy: dla pliku, projektu lub solucji.

Podsumowanie

Na końcu konfiguracji FxCopa i StyleCopa wszystkie nasze zmiany powinny wyglądać następująco:

Może nasuwać się pytanie, czemu tworzymy plik GlobalSuppressions.cs dla każdego projektu? Różne projekty mogą mieć różne reguły. Dodatkowo tworząc jeden globalny plik konfiguracyjny sprawiamy, że jego edycja wpływa na całą solucję – w ten sposób wyrzucając jeden Suppress możemy spowodować, że każdy projekt w solucji będzie miał nowe błędy i trudniej będzie to naprawić na tak dużym zbiorze.

Ciekawostka

Kończąc pisząc ten post natknęłam się na wpis mojego znajomego Michała Jankowskiego, który również poruszał ten temat na swoim blogu. Michał dorzucił jeszcze informacje o innych narzędziach do analizy kodu -podrzucam Wam linka.

---