Ricerca di "codice guasto" in un'applicazione legacy C++ di grandi dimensioni

Question

Attualmente sto lavorando a un'applicazione C++ grande e vecchia che ha avuto molti sviluppatori prima di me. C'è un sacco di "codice morto" nel progetto, classi e funzioni che non sono più utilizzate da nessuno.

Quali strumenti sono disponibili per C++ per eseguire un'analisi di base di codice di grandi dimensioni per rilevare e rifattorizzare il codice guasto? Nota: non sto parlando di strumento di copertura del test come gcov.

Come si trova il codice guasto nel progetto?

Answer 1

Ti consigliamo di utilizzare uno strumento dianalisi statica

• StackOverflow: What open source C++ static analysis tools are available?
• StackOverflow: C++ static code analysis tool on Windows
• Wikipedia: List of tools for static code analysis

Il Gotcha principale che ho incontrato in è che devi stare attento che tutte le librerie non vengono utilizzate da qualche parte che non c ontrollo/avere. Se elimini una funzione da una classe che viene utilizzata facendo riferimento a una libreria nel tuo progetto, puoi rompere qualcosa che non sapevi usare il codice.

Answer 2

Anche se non specificamente per codice morto, ho trovato il navigatore Fonte

http://sourcenav.berlios.de/

molto utile, anche se ingombrante per impostare e un po 'buggy. È stato un anno fa su Linux (Fedora).

Answer 3

Un approccio consiste nell'utilizzare la voce di menu di scelta rapida "Trova tutti i riferimenti" sui nomi di classi e funzioni. Se una classe/funzione è di riferimento solo in sé, è quasi sicuramente un codice morto.

Un altro approccio, basato sulla stessa idea, è quello di rimuovere (commentare) file/funzioni dal progetto e vedere quali messaggi di errore si otterranno.

Answer 4

Penso che la soluzione migliore sarebbe probabilmente uno strumento di copertura. Ce ne sono molte sia per * nix che per windows. Se hai dei test unitari, è facile: se hai una copertura di test bassa, il codice scoperto è morto o non ancora testato (vuoi comunque entrambi i pezzi di queste informazioni). Se non si dispone di test unitari, creare l'app con la strumentazione fornita da uno di questi strumenti, eseguirla attraverso alcuni (dovrebbe essere idealmente) i percorsi di esecuzione e visualizzare il report. Ottieni le stesse informazioni con i test unitari, richiederà solo molto più lavoro.

Dal momento che si sta utilizzando VisualStudio, mi potrebbe fornire paio di link che si potrebbe considerare l'utilizzo:

• Coverage meter
• BullseyeCoverage

Nessuno di loro è libero, neppure a buon mercato , ma di solito ne vale la pena.

Su piattaforme * nix gcov accoppiate con strumenti come zcov o lcov è una scelta davvero eccezionale.

Answer 5

Niente batte la familiarità con il codice.Tranne forse potature rigorose come si va avanti.

A volte quello che sembra deadwood viene utilizzato come impalcatura per i test unitari ecc., O sembra essere vivo semplicemente perché i test di unità legacy lo esercitano, ma non viene mai esercitato al di fuori dei test. Poco fa ho rimosso più di 1000 LOC che era di supporto esterni traduttori modello CAD, abbiamo avuto le prove che invocano quei traduttori esterni ma quei traduttori era stato supportato per 8+ anni e non c'era modo che un utente dell'applicazione, anche se volevano potrebbe mai invocarli.

A meno che uno non sia rigoroso a sbarazzarsi del legno morto, si troverà la tua squadra a mantenere la roba per anni.

Answer 6

Vedi il nostro SD C++ Test Coverage.

È necessario eseguire molti test dinamici per esercitare il codice, per assicurarsi di raggiungere la quantità massima di copertura. Il codice "non coperto" può essere o non essere morto; forse non hai semplicemente un caso di prova per esercitarlo.

Answer 7

Caolán McNamara's callcatcher viene utilizzato molto efficacemente all'interno del progetto LibreOffice (~ 6 MLOC) per trovare il codice morto.

Answer 8

È possibile utilizzare Cppcheck per questo scopo:

$ cppcheck --enable=unusedFunction . 
Checking 2380153.c... 
1/2 files checked 0% done 
Checking main.c... 
2/2 files checked 0% done 
[2380153.c:1]: (style) The function '2380153' is never used.