Trova codice inutilizzato [chiuso]

Devo refactificare una grande applicazione C # e ho trovato molte funzioni che non sono mai state utilizzate. Come posso verificare il codice inutilizzato, in modo da poter rimuovere tutte le funzioni inutilizzate?

Sì, ReSharper fa questo. Fare clic destro sulla soluzione e selezionare "Trova problemi di codice". Uno dei risultati è "Simboli inutilizzati". Questo ti mostrerà classi, metodi, ecc. Che non vengono utilizzati.

È un'ottima domanda, ma tieni presente che stai calpestando acque pericolose. Quando si elimina il codice, è necessario assicurarsi di compilare e testare spesso.

Un grande strumento viene in mente:

NDepend - questo strumento è semplicemente fantastico. Ci vuole un po 'di tempo per grok, e dopo i primi 10 minuti penso che la maggior parte degli sviluppatori dica semplicemente "Fanculo!" ed elimina l'app. Una volta che hai acquisito una buona idea di NDepend, ti offre una visione straordinaria di come le tue app sono accoppiate. Controlla: http://www.ndepend.com/ . Ancora più importante, questo strumento ti permetterà di visualizzare metodi che non hanno chiamanti diretti. Ti mostrerà anche l'inverso, un albero di chiamata completo per qualsiasi metodo nell'assieme (o anche tra assiemi).

Qualunque strumento tu scelga, non è un compito da prendere alla leggera. Soprattutto se hai a che fare con metodi pubblici su assiemi di tipi di libreria, poiché potresti non sapere mai quando un'app li sta facendo riferimento.

Resharper è buono per questo, come altri hanno affermato. Attenzione però, questi strumenti non trovano il codice utilizzato da reflection, ad esempio non possono sapere se un codice NON viene utilizzato da reflection.

Come ha sottolineato Jeff, lo strumento NDepend può aiutare a trovare metodi, campi e tipi inutilizzati.

Per elaborare un po ', NDepend propone di scrivere Code Rule su LINQ Query (CQLinq) . Vengono proposte circa 200 regole di codice predefinite , 3 delle quali dedicate al rilevamento di codici inutilizzati / morti

Fondamentalmente una tale regola per rilevare un metodo inutilizzato ad esempio assomiglia a:

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

Ma questa regola è ingenua e restituirà banali falsi positivi. Ci sono molte situazioni in cui un metodo non viene mai chiamato ma non è inutilizzato (entry point, costruttore di classi, finalizzatore ...) per questo le 3 regole predefinite sono più elaborate:

• Tipi potenzialmente morti (quindi rileva classe, struttura, interfaccia, delegato inutilizzati ...)
• Metodi potenzialmente morti
• Campi potenzialmente morti

NDepend si integra in Visual Studio 2017, 2015, 2013, 2012, 2010, quindi queste regole possono essere controllate / sfogliate / modificate direttamente all'interno dell'IDE . Lo strumento può anche essere integrato nel processo dell'elemento della configurazione e può creare report che mostreranno le regole violate e gli elementi del codice colpevole. NDepend ha anche un'estensione VS Team Services .

Se fai clic su questi 3 collegamenti sopra per il codice sorgente di queste regole, vedrai che quelli relativi a tipi e metodi sono un po 'complessi. Questo perché rilevano non solo tipi e metodi non utilizzati, ma anche tipi e metodi utilizzati solo da tipi e metodi morti non utilizzati (ricorsivi).

Questa è un'analisi statica , quindi il prefisso Potenzialmente nei nomi delle regole. Se viene utilizzato solo un elemento di codice tramite reflection, queste regole potrebbero considerarlo inutilizzato, il che non è il caso.

Oltre a utilizzare queste 3 regole, consiglierei di misurare la copertura del codice mediante test e di cercare di avere una copertura completa. Spesso, vedrai che il codice che non può essere coperto dai test, è in realtà un codice inutilizzato / morto che può essere scartato in modo sicuro. Ciò è particolarmente utile in algoritmi complessi in cui non è chiaro se un ramo di codice sia raggiungibile o meno.

Disclaimer: lavoro per NDepend.

Vorrei anche menzionare che l'uso del CIO alias Unity può rendere fuorvianti queste valutazioni. Potrei aver sbagliato, ma diverse classi molto importanti che vengono istanziate tramite Unity sembrano non avere istanze per quanto ReSharper può dire. Se avessi seguito i consigli di ReSharper, sarei stato spazzato via!

ReSharper fa un ottimo lavoro nel trovare codice inutilizzato.

In VS IDE, è possibile fare clic con il pulsante destro del mouse sulla definizione e scegliere "Trova tutti i riferimenti", sebbene funzioni solo a livello di soluzione.

La verità è che lo strumento non può mai darti una risposta certa al 100%, ma lo strumento di copertura può darti una buona corsa per i soldi.

Se si conta con una suite di unit test completa, è possibile utilizzare lo strumento di copertura test per vedere esattamente quali righe di codice non sono state eseguite durante l'esecuzione del test. Sarà comunque necessario analizzare il codice manualmente: eliminare ciò che si considera codice morto o scrivere test per migliorare la copertura del test.

Uno di questi strumenti è NCover , con precursore open source su Sourceforge . Un'altra alternativa è PartCover .

Dai un'occhiata a questa risposta su StackOverflow.

Mi sono imbattuto in AXTools CODESMART..Provalo una volta. Utilizza l'analizzatore di codice nella sezione recensioni, che elenca le funzioni locali e globali non funzionanti insieme ad altri problemi.

FXCop è un analizzatore di codice ... Fa molto di più che trovare codice inutilizzato. Ho usato FXCop per un po 'e sono rimasto così perso nei suoi consigli che l'ho disinstallato.

Penso che NDepend sembri un candidato più probabile.