Comment définissez-vous le «code indésirable»?

Question

Comment définiriez-vous le "code non désiré"?

Modifier:

IMHO, Tout membre de code avec 0 membre appelant actif (vérifié récursivement) est du code indésirable. (les fonctions, les méthodes, les propriétés, les variables sont des membres)

Answer 1

0 appels actifs et aucune possibilité d'utilisation dans un proche avenir. Et je préfère ne jamais commenter quoi que ce soit au cas où j'en aurais besoin plus tard, car j'utilise SVN (contrôle de source).

Answer 2

Voici ma définition du code non souhaité :

• Un code qui ne s'exécute pas est un poids mort. (À moins que ce ne soit une charge [malveillante] pour votre code réel, mais c'est une autre histoire: -))
• Un code qui se répète plusieurs fois augmente le coût du produit.
• Un code qui ne peut pas être testé par régression augmente également le coût du produit.

Vous pouvez supprimer ce code ou le refactoriser, mais vous ne souhaitez pas le conserver tel quel.

Answer 3

Comme vous l'avez dit dans l'autre fil de discussion, un code qui n'est utilisé nulle part est plutôt indésirable. Quant à savoir comment le trouver, je suggérerais FindBugs ou CheckStyle si vous utilisiez Java, par exemple, puisque ces outils vérifient si une fonction est utilisée n'importe où et la marque comme non utilisée si ce n'est pas le cas. Très agréable pour se débarrasser du poids inutile.

Answer 4

Eh bien, après y avoir pensé un peu, j’ai trouvé ces trois points:

• il peut s'agir d'un code qui devrait être refactoré
• il peut s'agir d'un code qui n'est plus appelé (restes des versions précédentes)
• il peut s'agir d'un code qui ne s'applique pas à votre guide de style ni à votre méthode de codage

Je parie qu'il y en a beaucoup plus, mais c'est comme ça que je définirais le code indésirable.

Answer 5

En Java, je marquerais la méthode ou la classe avec @Deprecated.

Answer 6

Tout membre de code PRIVATE sans membre appelant actif (vérifié de manière récursive). Sinon, vous ne savez pas si votre code n'est pas utilisé en dehors de votre analyse de périmètre.

Answer 7

Certaines choses sont déjà publiées, mais en voici une autre: Fonctions qui font presque la même chose. (seule une petite variable change et par conséquent toutes les fonctions sont copiées et cette variable est modifiée)

Answer 8

D'habitude, je dis à mon compilateur d'être aussi bruyant que possible, ce qui sélectionne 60% des éléments à examiner. Les fonctions inutilisées datant de plusieurs mois (après vérification auprès du VCS) sont généralement évincées, à moins que leur auteur ne me dise quand elles seront réellement utilisées. Stuff de prototypes manquants est également instantanément suspect.

Je pense qu'essayer de mettre en place un ménage automatisé, c'est comme essayer de faire un périphérique USB qui garantisse que vous jouez en toute sécurité Roulette russe .

Les composants les plus difficiles à vérifier sont les composants ajoutés au système de compilation. Peu de personnes s'aperçoivent que ces derniers et les kludges inutilisés restent pour collecter la mousse.

Au-delà de cela, je veux généralement le code, je veux juste que son auteur le refactorise un peu et rende son style identique à celui du reste du projet.

Un autre outil utile est doxygen , qui vous aide (visuellement) à voir les relations dans l'arborescence des sources. Cependant, si son objectif est de ne pas extraire de symboles / objets statiques, il ne sera pas très complet.