Comment trouver du code inutilisé/mort dans les projets java

Un plugin Eclipse qui fonctionne raisonnablement bien est Détecteur de code inutilisé.

Il traite un projet entier, ou un fichier spécifique et affiche diverses méthodes de code inutilisées/mortes, ainsi que suggérant des changements de visibilité (c'est-à-dire une méthode publique qui pourrait être protégée ou privée).

CodePro a été récemment publié par Google avec le projet Eclipse. Il est gratuit et très efficace. Le plugin a une fonctionnalité' Find Dead Code ' avec un/plusieurs points d'entrée. Fonctionne assez bien.

Je suis surpris ProGuard n'a pas été mentionné ici. C'est l'un des la plupart des produits matures autour de.

ProGuard est un fichier de classe Java gratuit shrinker, optimizer, obfuscator, et prévérificateur. Il détecte et supprime les classes, les champs inutilisés, méthodes et attributs. Il optimise le bytecode et supprime inutilisé instruction. Il renomme les classes, champs et méthodes restants en utilisant des noms courts sans signification. Enfin, il prévérifie le traité code pour Java 6 ou pour Java Micro Edition.

Certaines utilisations de ProGuard sont:

• Création de code plus compact, pour des archives de code plus petites, un transfert plus rapide sur les réseaux, un chargement plus rapide et une mémoire plus petite empreinte.
• Rendre les programmes et les bibliothèques plus difficiles à désosser.
• Liste du code mort, de sorte qu'il peut être supprimé du code source.
• Reciblage et pré-vérification des fichiers de classe existants pour Java 6 ou supérieur, pour prendre avantage de leur chargement de classe plus rapide.

Une chose que j'ai été connu pour faire dans Eclipse, sur une seule classe, est de changer toutes ses méthodes en privé, puis de voir quelles plaintes je reçois. Pour les méthodes utilisées, cela provoquera des erreurs et je les ramène au niveau d'accès le plus bas possible. Pour les méthodes qui ne sont pas utilisées, cela provoquera des avertissements sur les méthodes inutilisées, et celles-ci peuvent ensuite être supprimées. Et en prime, vous trouvez souvent des méthodes publiques qui peuvent et doivent être rendues privées.

Mais c'est très manuel.

Utilisez un outil de couverture de test pour instrumenter votre base de code, puis exécutez l'application elle-même, pas les tests.

Emma et Eclemma vous donneront de bons rapports sur le pourcentage de classes exécutées pour une exécution donnée du code.

Nous avons commencé à utiliser Find Bugs pour aider à identifier une partie du funk dans l'environnement riche en cibles de notre base de code pour les refactorings. Je considérerais également Structure 101 pour identifier les taches dans l'architecture de votre base de code qui sont trop compliquées, afin que vous sachiez où se trouvent les vrais marécages.

En théorie, vous ne pouvez pas trouver de manière déterministe du code inutilisé. Il y a une preuve mathématique de cela (eh bien, c'est un cas particulier d'un théorème plus général). Si vous êtes curieux, cherchez le problème d'arrêt.

Cela peut se manifester dans le code Java de plusieurs façons:

• Chargement des classes en fonction des entrées utilisateur, des fichiers de configuration, des entrées de base de données, etc.;
• Chargement du code externe;
• Passer des arborescences d'objets à des bibliothèques tierces;
• etc.

Cet être dit, j'utilise IDEA IntelliJ comme monE de choix et il a des outils d'analyse étendus pour les dépendances findign entre les modules, les méthodes inutilisées, les membres inutilisés, les classes inutilisées, etc. C'est assez intelligent aussi comme une méthode privée qui n'est pas appelée est étiquetée inutilisée mais une méthode publique nécessite une analyse plus approfondie.

Dans Eclipse Aller à Windows > Préférences > Java > Compilateur > Erreurs/Avertissements
et changez-les tous en erreurs. Corrigez toutes les erreurs. C'est la façon la plus simple. La beauté est que cela vous permettra de nettoyer le code que vous écrivez.

Capture d'écran Eclipse Code:

IntelliJ a des outils d'analyse de code pour détecter le code qui n'est pas utilisé. Vous devriez essayer de rendre autant de champs / méthodes / classes que possible non publics et cela affichera plus de méthodes/champs/classes inutilisés

J'essaierais également de localiser le code en double comme moyen de réduire le volume de code.

Ma dernière suggestion est d'essayer de trouver du code open source qui, s'il était utilisé, rendrait votre code plus simple.

La Structure101slice perspective donnera une liste (et un graphique de dépendance) de tous les "orphelins" ou "orphelinsgroupes " de classes ou de paquets qui n'ont pas de dépendances vers ou depuis le cluster "principal".

DCD n'est pas un plugin pour certainsE mais peut être exécuté à partir de ant ou autonome. Il ressemble à un outil statique et il peut faire ce que PMD et FindBugs ne peuvent pas . Je vais l'essayer.

P.S. Le Projet semble mort maintenant. Il y a un plugin PMD maintenant, mais je ne l'ai pas utilisé.

Il existe des outils qui profilent le code et fournissent des données de couverture de code. Cela vous permet de voir (comme le code est exécuté) combien il est appelé. Vous pouvez obtenir l'un de ces outils pour savoir combien de code orphelin vous avez.

• FindBugs est excellent pour ce genre de chose.
• PMD (Project Mess Detector) est un autre outil qui peut être utilisé.

Cependant, aucun des deux ne peut trouver les méthodes statiques publiques qui ne sont pas utilisées dans un espace de travail. Si quelqu'un connaît un tel outil, faites-le moi savoir.

Outils de couverture des utilisateurs, tels que EMMA. Mais ce n'est pas un outil statique (c'est-à-dire qu'il faut réellement exécuter l'application par des tests de régression, et par tous les cas d'erreur possibles, ce qui est, eh bien, impossible:))

Pourtant, EMMA est très utile.

Les outils de couverture de code, tels que Emma, Cobertura et Clover, instrumentaliseront votre code et enregistreront quelles parties de celui-ci sont invoquées en exécutant une suite de tests. Ceci est très utile et devrait faire partie intégrante de votre processus de développement. Cela vous aidera à déterminer dans quelle mesure votre suite de tests couvre votre code.

Cependant, ce n'est pas la même chose que d'identifier un vrai code mort. Il identifie uniquement le code couvert (ou non) par les tests. Cela peut vous donner des faux positifs (si votre les tests ne couvrent pas tous les scénarios) ainsi que les faux négatifs (si vos tests accèdent au code qui n'est en fait jamais utilisé dans un scénario réel).

J'imagine que la meilleure façon d'identifier vraiment le code mort serait d'instrumenter votre code avec un outil de couverture dans un environnement en direct et d'analyser la couverture du code sur une période prolongée.

Si vous exécutez dans un environnement redondant équilibré en charge (et sinon, pourquoi pas?) alors je suppose qu'il serait logique de seulement instrumentez une instance de votre application et configurez votre équilibreur de charge de telle sorte qu'une partie aléatoire, mais petite, de vos utilisateurs s'exécute sur votre instance instrumentée. Si vous faites cela sur une longue période de temps (pour vous assurer que vous avez couvert tous les scénarios d'utilisation du monde réel - de telles variations saisonnières), vous devriez être en mesure de voir exactement quelles zones de votre code sont accessibles sous utilisation du monde réel et quelles parties ne sont vraiment jamais accessibles et donc du code mort.

Je n'ai jamais personnellement vu cela fait, et je ne sais pas comment les outils susmentionnés peuvent être utilisés pour instrumenter et analyser du code qui n'est pas invoqué via une suite de tests - mais je suis sûr qu'ils peuvent l'être.

Il existe un projet Java - Détecteur de code mort (DCD). Pour le code source, cela ne semble pas bien fonctionner, mais pour .fichier jar - c'est vraiment bon. De plus, vous pouvez filtrer par classe et par méthode.

Netbeans voici un plugin pour Netbeans code mort détecteur de.

Il serait préférable qu'il puisse lier et mettre en évidence le code inutilisé. Vous pouvez voter et commenter ici: Bug 181458-Trouver les classes publiques inutilisées, méthodes, champs

Eclipse peut afficher/mettre en surbrillance le code qui ne peut pas être atteint. JUnit peut vous montrer la couverture du code, mais vous auriez besoin de quelques tests et devez décider si le test pertinent est manquant ou si le code est vraiment inutilisé.

J'ai trouvé l'outil Clover coverage qui code et met en évidence le code utilisé et inutilisé. Contrairement à Google CodePro Analytics, il fonctionne également pour les applications Web (selon mon expérience et je peux être incorrect sur Google CodePro).

Le seul inconvénient que j'ai remarqué est qu'il ne prend pas en compte les interfaces Java.

J'utilise Doxygen pour développer une carte d'appel de méthode pour localiser les méthodes qui ne sont jamais appelées. Sur le graphique, vous trouverez des îlots de clusters de méthodes sans appelants. Cela ne fonctionne pas pour les bibliothèques car vous devez toujours commencer à partir d'un point d'entrée principal.