2009-11-10 43 views
5

Esiste uno strumento di analisi del codice statico open source che può aiutare a trovare il codice irraggiungibile/non utilizzato nei programmi C#?Strumento open source per trovare codice C# irraggiungibile/non utilizzato

+0

Er, Visual Studio fornisce avvisi relativi al codice non raggiungibile o non utilizzato ... – Joren

+6

Solo segmenti di funzioni non utilizzati, gestiti dal compilatore, non VS. Ho la sensazione che l'OP stia parlando di funzioni completamente inutilizzate/non richiamate, che non sono gestite dal compilatore. –

+2

@ ApoY2k irraggiungibile sì. Supponi di dichiarare un metodo ma non chiamarlo mai, che non è supportato AFAIK. – ParmesanCodice

risposta

5

FxCop, che è incorporato nelle edizioni superiori di Visual Studio, avviserà di membri privati ​​o interni non utilizzati. Fai clic con il pulsante destro del mouse sul progetto e seleziona Esegui analisi del codice. In congiunzione con "segmenti di codice irraggiungibili" identificati dal compilatore come altri hanno notato, questo dovrebbe catturare il codice inutilizzato rimanente.

(Nota FxCop sarà non avvisate dei membri pubblici o protetti inutilizzati, perché questi potrebbero essere parte di un'API destinato ad essere utilizzato dai chiamanti esterni. Inoltre, FxCop non è disponibile in tutte le edizioni di Visual Studio se le versioni più vecchie sono disponibile per il download.)

+0

FxCop è disponibile separatamente da VS anche se per quanto ne so io (so che è disponibile separatamente, è la parte gratuita di cui non sono sicuro). –

+0

Sì, separato e gratuito. – Cheeso

1

Il meglio che posso suggerire è uno strumento di copertura del codice utilizzato nell'esecuzione principale anziché in un assembly di test, quindi inserire l'applicazione attraverso i suoi passi ... Un'analisi statica del codice sarebbe NP difficile da fare in alcuni più esoterici casi.

+2

È molto peggio di NP-HARD. Un'analisi statica esatta della copertura del codice è praticamente * per definizione * il problema dell'arresto. Chiaramente la domanda "questa linea di codice mai eseguita" equivale a "il programma si ferma mai?" (Basta sostituire ogni interruzione nel programma con un loop infinito, e la linea in questione con una battuta d'arresto, e quindi eseguire il rilevatore di arresto.) Il problema di interruzione non è certamente NP-HARD; è indiscutibile. –

+0

@Eric: mi sono fermato poco prima di menzionare The Halting Problem, perché mentre suonava giusto per me, non ero abbastanza sicuro che fosse applicabile in questo caso. –

1

Sebbene non sia uno strumento open source, è possibile utilizzare R# (Resharper). è un add-in di Visual Studio in grado di mostrarti codice non raggiungibile e di rimuoverlo automaticamente (usando la pulizia del sistema).

+3

È ** non ** open source, vero? –

+0

È almeno gratuito (o gratuito) o devi comprarlo? – hasen

+1

Non è gratuito ma puoi usare la versione beta gratuita (almeno per ora) - le versioni notturne sono disponibili su: http://www.jetbrains.net/confluence/display/ReSharper/ReSharper+5.0+Nightly+Builds –

0

È possibile utilizzare lo strumento di copertura del codice, disponibile in Visual Studio 2005/2008 Team Suite.

-1

Lo strumento NDepend può aiutare a trovare il codice inutilizzato in una base di codice .NET. Tuttavia questo strumento non è Open Source. Disclaimer: Sono uno degli sviluppatori di questo strumento.

NDepend propone di scrivere Code Rule over LINQ Query (CQLinq). Intorno 200 default code rules sono proposte, 3 delle quali è dedicata ad codice inutilizzato/dead rilevamento:

NDepend è integrato in Visual Studio, quindi queste regole possono essere checked/browsed/edited right inside the IDE. Lo strumento può anche essere integrato nel processo CI e può creare reports che mostrerà le regole violate e gli elementi del codice colpevole.

Se si fa clic su questi 3 collegamenti sopra verso il codice sorgente di queste regole, vedrete 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 usati solo da tipi e metodi morti non utilizzati (ricorsivo).

Questo è analisi statica, qui il prefisso Potenzialmente nei nomi delle regole. Se si utilizza un elemento codice solo tramite riflessione, è possibile che queste regole lo considerino inutilizzato e non lo è.

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

Problemi correlati