Trouver le "code mort" dans une grande application C++ héritée du passé

Question

Je travaille actuellement sur une importante et ancienne application C++ qui a connu de nombreux développeurs avant moi. Il y a beaucoup de "code mort" dans le projet, des classes et des fonctions qui ne sont plus utilisées par personne.

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

Comment trouver le code mort dans votre projet ?

Answer 1

Vous voudrez utiliser un analyse statique outil

• StackOverflow : Quels sont les outils d'analyse statique C++ à code source ouvert disponibles ?
• Wikipedia : Liste d'outils pour l'analyse statique du code

Le principal problème que j'ai rencontré est que vous devez faire attention à ce que les bibliothèques ne soient pas utilisées à partir d'un endroit que vous ne contrôlez pas. Si vous supprimez une fonction d'une classe qui est utilisée en faisant référence à une bibliothèque dans votre projet, vous pouvez casser quelque chose dont vous ne saviez pas que le code était utilisé.

Answer 2

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

Answer 3

Je pense que votre meilleure chance serait probablement un outil de couverture. Il y en a beaucoup pour *nix et Windows. Si vous avez des tests unitaires, c'est facile - si vous avez une faible couverture de test, alors le code non couvert est soit mort, soit pas encore testé (vous voulez les deux éléments de cette information de toute façon). Si vous n'avez pas de tests unitaires, construisez votre application avec l'instrumentation fournie par l'un de ces outils, exécutez-la par quelques chemins d'exécution (idéalement tous), et consultez le rapport. Vous obtiendrez les mêmes informations qu'avec les tests unitaires, mais cela vous demandera beaucoup plus de travail.

Puisque vous utilisez VisualStudio, je peux vous fournir quelques liens que vous pouvez envisager d'utiliser :

• Compteur de couverture
• BullseyeCouverture

Aucune d'entre elles n'est gratuite, ni même bon marché, mais le résultat en vaut généralement la peine.

Sur les plates-formes de type *nix gcov couplé à des outils comme zcov o lcov est un très bon choix.

Answer 4

Rien ne vaut la familiarité avec le code. Sauf peut-être un élagage rigoureux au fur et à mesure.

Parfois, ce qui ressemble à du bois mort est utilisé comme échafaudage pour les 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 peu de temps, j'ai supprimé plus de 1000 LOC qui prenaient en charge des traducteurs externes de modèles de CAO. Nous avions des tests qui invoquaient ces traducteurs externes, mais ces traducteurs n'étaient plus pris en charge depuis plus de huit ans et il était impossible pour un utilisateur de l'application, même s'il le voulait, de les invoquer.

Si l'on ne se débarrasse pas rigoureusement du bois mort, on verra votre équipe entretenir le matériel pendant des années.

Answer 5

Une approche consiste à utiliser l'élément de menu contextuel "Find All References" sur les noms de classes et de fonctions. Si une classe/fonction n'est référencée qu'en elle-même, il s'agit presque certainement de code mort.

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