Quels outils d'analyse de code utilisez-vous pour vos projets Java? [fermé]

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 tous les autres)
• tout autre outil basé sur l'instrumentation
• autre chose, si je 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, par exemple, plugin d'outil de construction), ces informations méritent également d'être notées.

Pour les outils d'analyse statique, j'utilise souvent CPD, PMD , FindBugs et Checkstyle .

CPD est l'outil PMD "Copy / Paste Detector". J'utilisais PMD pendant un petit moment avant de remarquer le lien «Finding Duplicated Code» sur la page Web PMD .

Je tiens à souligner que ces outils peuvent parfois être étendus au-delà de leur ensemble de règles «prêt à l'emploi». Et pas seulement parce qu'ils sont open source afin que vous puissiez les réécrire. Certains de ces outils sont livrés avec des applications ou "hooks" qui leur permettent d'être étendus. Par exemple, PMD est fourni avec l' outil "designer" qui vous permet de créer de nouvelles règles. En outre, Checkstyle a la vérification DescendantToken qui a 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 construction, je trouve utile de configurer les outils pour qu'ils soient quelque peu «intégrés» de plusieurs autres manières. À savoir, la génération de rapports et l'uniformité de la suppression des avertissements. Je voudrais ajouter ces aspects à cette discussion (qui devrait probablement avoir la balise "static-analysis" aussi): 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

Ceci est souvent appelé 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 des chaînes de filtres Ant .

La deuxième "intégration" que je fais est pour 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 diverses demandes de suppression d'avertissement n'ont pas un aspect cohérent 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 l' @SuppressWarningsannotation Java . Je configure PMD pour utiliser des commentaires contenant " SuppressWarning(PMD." au lieu de NOPMDpour que les suppressions PMD se ressemblent. Je remplis la règle particulière violée lors de l'utilisation de la suppression du style de commentaire:

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

Seule la SuppressWarnings(PMD.partie " " est significative pour un commentaire, mais elle est cohérente avec la prise en charge par PMD de l' @SuppressWarningannotation qui reconnaît les violations de règle individuelles par leur nom:

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

De même, Checkstyle supprime la génération d'avertissements entre les paires de commentaires (aucune prise en charge d'annotation n'est fournie). Par défaut, les commentaires pour activer et désactiver Checkstyle contiennent les chaînes CHECKSTYLE:OFFet CHECKSTYLE:ON, respectivement. Changer cette configuration (avec "SuppressionCommentFilter" de Checkstyle) pour utiliser les chaînes " BEGIN SuppressWarnings(CheckStyle." et " END SuppressWarnings(CheckStyle." fait que les contrôles ressemblent davantage à 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 significative car chaque vérification a sa propre BEGIN/ENDpaire de commentaires " ".

FindBugs prend également en charge la suppression de la génération d'avertissement avec une @SuppressWarningsannotation, de sorte qu'aucune configuration supplémentaire n'est nécessaire pour atteindre un certain niveau d'uniformité avec d'autres outils. Malheureusement, Findbugs doit prendre en charge une @SuppressWarningsannotation personnalisée car l' @SuppressWarningsannotation Java intégrée a une SOURCEpolitique 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 entièrement les suppressions d'avertissements FindBugs pour éviter les conflits avec l' @SuppressWarningsannotation de Java :

@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 le fait que chaque suppression d'avertissement contienne la chaîne " SuppressWarnings" facilite l'exécution d'une recherche simple pour trouver toutes les instances de tous les outils sur une base de code entière.

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

EclEmma est un plugin Eclipse génial qui montre 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 juste 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 a des plugins de rapport 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 agrégés. Ceux-ci sont générés par nos builds CI, qui fonctionnent à l'aide de Continuum .

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

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

De plus, dans nos builds Maven, nous avons:

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

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

Remarque: Clover a une intégration prête à l'emploi avec le serveur Bamboo CI (car ils sont tous deux des produits Atlassian). Il existe également des plugins Bamboo pour FindBugs, PMD et CheckStyle, mais, comme indiqué, le serveur gratuit Hudson CI en a aussi.

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, intégration parfaite.

Cette solution intégrée est fiable, puissante et facile à utiliser par rapport aux outils d'assemblage de divers fournisseurs.

Checkstyle est un autre que j'ai utilisé dans une entreprise précédente ... c'est principalement pour la vérification de style, mais il peut aussi faire une analyse statique. Aussi, Clover 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, pour soutenir 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 son aspect soigné lorsque vous exécutez javac dans la console Windows. : P

J'ai eu de la chance avec Cobertura. C'est 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 de 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 une belle histoire de la qualité de notre source et de la direction que nous empruntons. 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.

La structure 101 est bonne pour l'analyse de code et la recherche des dépendances cycliques des packages.

Je suis à la recherche de nombreuses réponses pour en savoir plus sur les nouveaux outils et consolider ces connaissances en une seule question / fil, donc je doute qu'il y ait une vraie réponse à cette question.

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

• Findbugs pour rechercher les erreurs courantes mauvais / codage - exécutez à partir de maven, et s'intègre également facilement dans Eclipse
• Cobertura pour nos rapports de couverture - Run from Maven

Hudson a également un plugin de scanner de tâches qui affichera un 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 gère nos versions lors de l'enregistrement ainsi que des choses supplémentaires tous les soirs et toutes les semaines. Les tendances Hudson représentent nos tests JUnit, la couverture, les bogues de recherche, ainsi que les 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.