Question

Quels outils d'analyse de code utilisez-vous sur vos projets Java ?

Je m'intéresse à toutes sortes

  • outils d'analyse de code statique (FindBugs, PMD et autres)
  • outils de couverture de code (Cobertura, Emma et tout autre)
  • tout autre outil basé sur l'instrumentation
  • autre chose, s'il me manque quelque chose

Le cas échéant, indiquez également les outils de build que vous utilisez et dans quelle mesure ces outils s'intègrent à la fois à vos IDE et à vos outils de build.

Si un outil n'est disponible que d'une manière spécifique (en tant que plugin IDE ou, disons, plugin d'outil de construction), cette information mérite également d'être notée.

Était-ce utile?

La solution

Pour les outils d'analyse statique, j'utilise souvent CPD, PMD, Rechercher des bogues, et Style de contrôle.

CPD est l'outil "Copy/Paste Detector" de PMD.J'utilisais PMD depuis un petit moment avant de remarquer le Lien "Recherche du code dupliqué" sur le Page Web du PMD.

Je voudrais souligner que ces outils peuvent parfois être étendus au-delà de leur ensemble de règles « prêtes à l'emploi ».Et pas seulement parce qu'ils sont open source pour que vous puissiez les réécrire.Certains de ces outils sont livrés avec des applications ou « hooks » qui permettent de les étendre.Par exemple, PMD est livré avec le outil "concepteur" cela vous permet de créer de nouvelles règles.De plus, Checkstyle a le DescendantToken chèque qui possède des propriétés qui permettent une personnalisation substantielle.

J'intègre ces outils avec une version basée sur Ant.Vous pouvez suivre le lien pour voir ma configuration commentée.

En plus de la simple intégration dans la version, je trouve utile de configurer les outils pour qu'ils soient quelque peu « intégrés » de plusieurs autres manières.À savoir, l’uniformité de la génération de rapports et de la suppression des avertissements.J'aimerais ajouter ces aspects à cette discussion (qui devrait probablement également avoir la balise "static-analysis") :comment les gens configurent-ils ces outils pour créer une solution « unifiée » ?(J'ai posé cette question séparément ici)

Tout d’abord, pour les rapports d’avertissement, je transforme la sortie afin que chaque avertissement ait le format simple :

/absolute-path/filename:line-number:column-number: warning(tool-name): message

C'est ce qu'on appelle souvent le « format Emacs », mais même si vous n'utilisez pas Emacs, c'est un format raisonnable pour homogénéiser les rapports.Par exemple:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

Mes transformations de format d'avertissement sont effectuées par mon script Ant avec Ant chaînes de filtres.

La deuxième « intégration » que je fais concerne la suppression des avertissements.Par défaut, chaque outil prend en charge les commentaires ou une annotation (ou les deux) que vous pouvez placer dans votre code pour faire taire un avertissement que vous souhaitez ignorer.Mais ces différentes demandes de suppression d’avertissements n’ont pas une apparence cohérente, ce qui semble quelque peu idiot.Lorsque vous supprimez un avertissement, vous supprimez un avertissement, alors pourquoi ne pas toujours écrire "SuppressWarning?"

Par exemple, la configuration par défaut de PMD supprime la génération d'avertissements sur les lignes de code avec la chaîne "NOPMD" dans un commentaire.De plus, PMD prend en charge Java @SuppressWarnings annotation.Je configure PMD pour utiliser des commentaires contenant "SuppressWarning(PMD." au lieu de NOPMD de sorte que les suppressions de PMD se ressemblent.Je remplis la règle particulière qui n'est pas respectée lors de l'utilisation de la suppression du style de commentaire :

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Seulement le "SuppressWarnings(PMD." une partie est significative pour un commentaire, mais elle est cohérente avec le soutien de PMD au @SuppressWarning annotation qui reconnaît les violations de règles individuelles par leur nom :

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

De même, Checkstyle supprime la génération d'avertissements entre des paires de commentaires (aucune prise en charge des annotations n'est fournie).Par défaut, les commentaires pour désactiver et activer Checkstyle contiennent les chaînes CHECKSTYLE:OFF et CHECKSTYLE:ON, respectivement.Changer cette configuration (avec le "SuppressionCommentFilter" de Checkstyle) pour utiliser les chaînes "BEGIN SuppressWarnings(CheckStyle." et "END SuppressWarnings(CheckStyle." fait ressembler les contrôles à PMD :

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

Avec les commentaires Checkstyle, la violation de vérification particulière (HiddenField) est important car chaque chèque a le sien "BEGIN/END" commentaire paire.

FindBugs prend également en charge la suppression de la génération d'avertissements avec un @SuppressWarnings annotation, donc aucune configuration supplémentaire n’est requise pour atteindre un certain niveau d’uniformité avec d’autres outils.Malheureusement, Findbugs doit prendre en charge un @SuppressWarnings annotation car le Java intégré @SuppressWarnings l'annotation a un SOURCE politique de rétention qui n'est pas assez forte pour conserver l'annotation dans le fichier de classe là où FindBugs en a besoin.Je qualifie pleinement les suppressions d'avertissements FindBugs pour éviter les conflits avec ceux de Java. @SuppressWarnings annotation:

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

Ces techniques rendent les choses raisonnablement cohérentes entre les outils.Notez que chaque suppression d'avertissement contient la chaîne "SuppressWarnings" facilite l'exécution d'une recherche simple pour trouver toutes les instances de tous les outils sur l'ensemble d'une base de code.

Autres conseils

J'utilise une combinaison de Cobertura, Checkstyle, (Ecl)Emma et Findbugs.

EclEmma est un génial Plugin Eclipse qui affiche la couverture du code en colorant la source Java dans l'éditeur (capture d'écran) - la couverture est générée en exécutant un test JUnit.Ceci est vraiment utile lorsque vous essayez de déterminer quelles lignes sont couvertes dans une classe particulière, ou si vous voulez voir quelles lignes sont couvertes par un seul test.C'est beaucoup plus convivial et utile que de générer un rapport puis de parcourir le rapport pour voir quelles classes ont une faible couverture.

Les plugins Checkstyle et Findbugs Eclipse sont également utiles, ils génèrent des avertissements dans l'éditeur au fur et à mesure que vous tapez.

Maven2 dispose de plugins de rapports qui fonctionnent avec les outils ci-dessus pour générer des rapports au moment de la construction.Nous l'utilisons pour obtenir des rapports globaux sur le projet, qui sont plus utiles lorsque vous souhaitez des chiffres globaux.Ceux-ci sont générés par nos builds CI, qui s'exécutent en utilisant Continuum.

Nous utilisons et intégrons facilement tous les éléments suivants dans nos versions Maven 2.x et Eclipse/RAD 7 :

  • Tests-JUnit/TestNG
  • Analyse de code - FindBugs, PMD
  • Couverture du code - Clover

De plus, dans nos builds Maven, nous avons :

  • JDépend
  • Vérificateur de balises (TODO, FIXME, etc.)

De plus, si vous utilisez Maven 2.x, CodeHaus propose une collection de plugins Maven pratiques dans leur Projet Mojo.

Note:Clover dispose d'une intégration prête à l'emploi avec le serveur Bamboo CI (puisqu'il s'agit tous deux de produits Atlassian).Il existe également des plugins Bamboo pour FindBugs, PMD et CheckStyle mais, comme indiqué, le serveur gratuit Hudson CI en possède également.

J'utilise l'analyse statique intégrée à IntelliJ IDEA.Intégration parfaite.

J'utilise la couverture de code intégrée à Intellij IDEA (basée sur EMMA).Encore une fois, une intégration parfaite.

Cette solution intégrée est fiable, puissante et facile à utiliser par rapport aux outils réunis de différents fournisseurs.

Style de contrôle en est un autre que j'ai utilisé dans une entreprise précédente...c'est principalement pour la vérification du style, mais il peut également effectuer une analyse statique.Aussi, Trèfle pour la couverture du code, mais sachez que ce n'est pas un outil gratuit.

Nous utilisons FindBugs et Checkstyle ainsi que Clover pour la couverture du code.

Je pense qu'il est important d'avoir une sorte d'analyse statique, soutenant votre développement.Malheureusement, l'importance de ces outils n'est pas encore largement répandue.

Nous utilisons FindBugs et JDepend intégrés à Ant.Nous utilisons JUnit mais nous n'utilisons aucun outil de couverture.

Je ne l'utilise pas intégré à Rational Application Developer (l'IDE que j'utilise pour développer des applications J2EE) car j'aime à quel point il est soigné lorsque vous exécutez javac dans la console Windows.:P

J'ai eu de la chance avec Cobertura.Il s'agit d'un outil de couverture de code qui peut être exécuté via votre script ant dans le cadre de votre build normal et peut être intégré à Hudson.

Notre équipe utilise PMD et Cobertura, en fait nos projets sont des projets maven et il est très simple d'inclure des plug-ins pour l'analyse du code.La vraie question serait pour un projet spécifique quelle analyse vous devez utiliser, mon avis est que vous ne pouvez pas utiliser les mêmes plugins pour chaque projet.

dans notre projet, nous utilisons Sonar devant checkstyle, pmd....avec le CI (Bamboo, Hudson), nous obtenons également un bel historique de la qualité de nos sources et de la direction que nous suivons.J'aime Sonar, car vous êtes un outil central dans la pile CI qui le fait pour vous, et vous pouvez facilement personnaliser les règles pour chaque projet.

Structure 101 est bon en analyse de code et en recherche des dépendances cycliques des packages.

Je recherche de nombreuses réponses pour découvrir de nouveaux outils et consolider ces connaissances dans une seule question/un seul fil de discussion, donc je doute qu'il y ait 1 vraie réponse à cette question.

Ma réponse à ma propre question est que nous utilisons :

  • Findbugs pour rechercher les erreurs/codages courants - exécuté à partir de maven et s'intègre également facilement dans Eclipse
  • Cobertura pour nos rapports de couverture - exécutés depuis maven

Hudson dispose également d'un plugin d'analyse de tâches qui affichera le nombre de vos TODO et FIXME, ainsi que leur emplacement dans les fichiers source.

Tous sont intégrés à Maven 1.x dans notre cas et liés à Hudson, qui exécute nos builds lors de l'enregistrement ainsi que des éléments supplémentaires tous les soirs et chaque semaine.La tendance Hudson représente graphiquement nos tests JUnit, notre couverture, nos recherches de bugs ainsi que nos tâches ouvertes.Il existe également un plugin Hudson qui rapporte et représente graphiquement nos avertissements de compilation.Nous avons également plusieurs tests de performances avec leurs propres graphiques de performances et d'utilisation de la mémoire au fil du temps en utilisant également le plugin Hudson plots.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top