Trouver du "code mort" dans une grande application C++ ancienne

Question

Je travaille actuellement sur une application C++ ancienne et grande qui a eu beaucoup de développeurs avant moi. Il y a beaucoup de «code mort» dans le projet, les classes et les fonctions qui ne sont plus utilisées par personne.

Quels outils sont disponibles pour C++ pour faire une analyse de base de code de grande taille pour détecter et refactoriser le code mort? Note: Je ne parle pas d'un outil de couverture de test comme gcov.

Comment trouvez-vous du code mort dans votre projet?

Answer 1

Vous voulez utiliser une analyse statique outil

• 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

Le principal Gotcha J'ai couru en est que vous devez faire attention que toutes les bibliothèques ne sont pas utilisées de quelque part que vous ne c ontrol/avoir. Si vous supprimez une fonction d'une classe qui est utilisée en référençant une bibliothèque dans votre projet, vous pouvez casser quelque chose que vous ne connaissez pas en utilisant le code.

Answer 2

Bien que pas spécifiquement pour le code mort, je trouve le navigateur Source

http://sourcenav.berlios.de/

très utile, bien que compliqué à mettre en place et un peu bogué. C'était il y a un an sur Linux (Fedora).

Answer 3

Une approche consiste à utiliser l'élément de menu contextuel «Rechercher toutes les références» sur les noms de classe et de fonction. Si une classe/fonction n'est référencée qu'en elle-même, c'est presque certainement du code mort.

Une autre approche, basée sur la même idée, consiste à supprimer (commenter) les fichiers/fonctions du projet et à voir les messages d'erreur que vous obtiendrez.

Answer 4

Je pense que votre meilleur pari serait probablement un outil de couverture. Il y en a plein pour les deux * nix et les fenêtres. Si vous avez des tests unitaires, c'est facile - si vous avez une couverture de test faible, alors le code non couvert est soit mort, soit pas encore testé (vous voulez quand même les deux parties de cette info). Si vous n'avez pas de tests unitaires, créez votre application avec l'instrumentation fournie par l'un de ces outils, exécutez-la via certains chemins d'exécution (idéalement) et consultez le rapport. Vous obtenez les mêmes informations qu'avec les tests unitaires, cela demandera seulement beaucoup plus de travail.

Puisque vous utilisez VisualStudio, je pourrais vous fournir quelques liens que vous pourriez envisager d'utiliser:

• Coverage meter
• BullseyeCoverage

Aucun d'entre eux est libre, même pas cher , mais le résultat en vaut généralement la peine.

Sur les plates-formes nix-like gcov couplé avec des outils comme zcov ou lcov est un très bon choix.

Answer 5

Rien ne vaut la familiarité avec le code.Sauf peut-être une taille rigoureuse au fur et à mesure. Parfois, ce qui ressemble au bois mort est utilisé comme échafaudage pour des tests unitaires, etc., ou il semble être vivant simplement parce que les tests unitaires existants l'exercent, mais il n'est jamais exercé en dehors des tests. Il y a quelques temps, j'ai supprimé plus de 1000 LOC qui supportaient des traducteurs de modèles CAO externes, nous avions des tests invoquant ces traducteurs externes mais ces traducteurs n'étaient pas supportés depuis plus de 8 ans et il n'y avait aucun moyen qu'un utilisateur de l'application pourrait jamais les invoquer.

À moins d'être rigoureux dans la façon de se débarrasser du bois mort, on trouvera que votre équipe entretient la substance pendant des années.

Answer 6

Voir notre SD C++ Test Coverage.

Vous devez faire beaucoup de tests dynamiques pour exercer le code, afin de vous assurer que vous atteignez le maximum de couverture. Le code "non couvert" peut ou peut ne pas être mort; peut-être n'avez-vous tout simplement pas de test pour l'exercer.

Answer 7

Le callcatcher de Caolán McNamara est très efficacement utilisé dans le projet LibreOffice (~ 6 MLOC) pour trouver du code mort.

Answer 8

Vous pouvez utiliser Cppcheck à cet effet:

$ 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.