Znajdź nieużywany kod [zamknięty]

Muszę refaktoryzować dużą aplikację w języku C # i znalazłem wiele funkcji, które nigdy nie są używane. Jak mogę sprawdzić nieużywany kod, aby usunąć wszystkie nieużywane funkcje?

Tak, ReSharper to robi. Kliknij prawym przyciskiem myszy swoje rozwiązanie i wybierz „Znajdź problemy z kodem”. Jednym z wyników jest „Nieużywane symbole”. Spowoduje to wyświetlenie klas, metod itp., Które nie są używane.

To świetne pytanie, ale ostrzegaj, że stąpasz tutaj w niebezpiecznych wodach. Usuwając kod, musisz często się kompilować i testować.

Przychodzi mi na myśl jedno świetne narzędzie:

NDepend - to narzędzie jest po prostu niesamowite. Grok zajmuje trochę czasu, a po pierwszych 10 minutach myślę, że większość programistów po prostu mówi „Pieprzyć to!” i usuń aplikację. Gdy już dobrze znasz NDepend, daje to niesamowity wgląd w sposób łączenia aplikacji. Sprawdź to: http://www.ndepend.com/ . Co najważniejsze, to narzędzie pozwoli ci zobaczyć metody, które nie mają żadnych bezpośrednich rozmówców. Pokaże także odwrotne, pełne drzewo wywołań dla dowolnej metody w zespole (a nawet między zespołami).

Bez względu na to, jakie narzędzie wybierzesz, nie jest to łatwe zadanie. Zwłaszcza jeśli masz do czynienia z metodami publicznymi na zestawach typów bibliotek, ponieważ możesz nigdy nie wiedzieć, kiedy aplikacja się do nich odwołuje.

Resharper jest do tego dobry, jak stwierdzili inni. Uważaj jednak, narzędzia te nie znajdują kodu używanego przez odbicie, np. Nie mogą wiedzieć, czy jakiś kod NIE jest używany przez odbicie.

Jak wskazał Jeff, narzędzie NDepend może pomóc znaleźć nieużywane metody, pola i typy.

Aby trochę rozwinąć, NDepend proponuje napisać Regułę Kodową nad Zapytaniem LINQ (CQLinq) . Proponowanych jest około 200 domyślnych reguł kodu , z których 3 poświęcone są wykrywaniu nieużywanego / martwego kodu

Zasadniczo taka reguła wykrywania nieużywanej metody wygląda na przykład:

// <Name>Dead Methods</Name>
warnif count > 0 
from m in Application.Methods where !m.MethodsCallingMe.Any()
select m

Ale ta zasada jest naiwna i zwróci trywialne fałszywe trafienia. Istnieje wiele sytuacji, w których metoda nigdy nie jest wywoływana, ale nie jest nieużywana (punkt wejścia, konstruktor klasy, finalizator ...), dlatego bardziej szczegółowe są 3 domyślne reguły:

• Potencjalnie martwe typy (stąd wykryj nieużywaną klasę, strukturę, interfejs, deleguj ...)
• Potencjalnie martwe metody
• Potencjalnie martwe pola

NDepend integruje się z Visual Studio 2017,2015, 2013, 2012, 2010, dlatego te reguły można sprawdzać / przeglądać / edytować bezpośrednio w środowisku IDE . Narzędzie może być również zintegrowane z procesem CI i może tworzyć raporty , które pokażą naruszone reguły i elementy kodu sprawcy. NDepend ma również rozszerzenie VS Team Services .

Jeśli klikniesz powyższe 3 linki w kierunku kodu źródłowego tych reguł, zobaczysz, że te dotyczące typów i metod są nieco złożone. Wynika to z tego, że wykrywają nie tylko nieużywane typy i metody, ale także typy i metody używane tylko przez nieużywane martwe typy i metody (rekurencyjne).

To jest analiza statyczna , stąd przedrostek Potencjalnie w nazwach reguł. Jeśli element kodu jest używany tylko przez odbicie, reguły te mogą uznać go za nieużywany, co nie jest prawdą.

Oprócz korzystania z tych 3 zasad, radziłbym mierzyć pokrycie kodu testami i dążyć do uzyskania pełnego zasięgu. Często widzisz, że kod, który nie może być objęty testami, jest faktycznie nieużywanym / martwym kodem, który można bezpiecznie usunąć. Jest to szczególnie przydatne w złożonych algorytmach, w których nie jest jasne, czy gałąź kodu jest osiągalna, czy nie.

Uwaga: Pracuję dla NDepend.

Chciałbym również wspomnieć, że stosowanie MKOl, czyli Unity, może wprowadzać te oceny w błąd. Mogłem się pomylić, ale wydaje się, że kilka bardzo ważnych klas, które są tworzone przez Unity, nie ma instancji, o ile ReSharper może to stwierdzić. Gdybym postępował zgodnie z zaleceniami ReSharpera, bym się nie podobał!

ReSharper świetnie sobie radzi ze znajdowaniem nieużywanego kodu.

W VS IDE możesz kliknąć definicję prawym przyciskiem myszy i wybrać „Znajdź wszystkie referencje”, chociaż działa to tylko na poziomie rozwiązania.

Prawda jest taka, że ​​to narzędzie nigdy nie da w 100% pewnej odpowiedzi, ale narzędzie pokrycia może dać całkiem niezłą szansę na pieniądze.

Jeśli liczysz z kompleksowym pakietem testów jednostkowych, możesz użyć narzędzia pokrycia testowego, aby zobaczyć dokładnie, które wiersze kodu nie zostały wykonane podczas uruchomienia testowego. Nadal będziesz musiał przeanalizować kod ręcznie: albo wyeliminuj to, co uważasz za martwy kod, albo napisz test, aby poprawić zasięg testu.

Jednym z takich narzędzi jest NCover , z prekursorem open source na Sourceforge . Inną alternatywą jest PartCover .

Sprawdź tę odpowiedź na stackoverflow.

Natknąłem się na CODESMART AXTools .. Spróbuj raz. Skorzystaj z analizatora kodu w dziale recenzji, który wyświetli martwe funkcje lokalne i globalne oraz inne problemy.

FXCop to analizator kodu ... Robi znacznie więcej niż znajdowanie nieużywanego kodu. Przez jakiś czas korzystałem z FXCop i byłem tak zagubiony w jego zaleceniach, że go odinstalowałem.

Myślę, że NDepend wygląda na bardziej prawdopodobnego kandydata.