Checkstyle vs PMD


86

Nous introduisons des outils d'analyse statique dans le système de construction de notre produit Java. Nous utilisons Maven2 donc l' intégration de Checkstyle et PMD est gratuite. Cependant, il semble qu'il y ait un grand chevauchement des fonctionnalités entre ces deux outils, en termes d'application des règles de style de base.

Y a-t-il un avantage à utiliser ces deux éléments? Je ne veux pas maintenir 2 outils si l'un d'entre eux fonctionne. Si nous en choisissons un, lequel devrions-nous utiliser et pourquoi?

Nous prévoyons également d'utiliser FindBugs. Y a-t-il d'autres outils d'analyse statique que nous devrions examiner?

Mise à jour: le consensus semble être que PMD est préféré à CheckStyle. Je ne vois pas de raison solide d'utiliser les deux, et je ne veux pas maintenir 2 ensembles de fichiers de règles, donc nous viserons probablement exclusivement PMD. Nous allons également intégrer FindBugs, et peut-être, éventuellement, Macker pour appliquer les règles architecturales.

Réponses:


71

Vous devez absolument utiliser FindBugs . D'après mon expérience, le taux de faux positifs est très faible et même les avertissements les moins critiques qu'il signale méritent d'être traités dans une certaine mesure.

En ce qui concerne Checkstyle vs PMD, je n'utiliserais pas Checkstyle car il ne concerne que le style. D'après mon expérience, Checkstyle rapportera une tonne de choses qui sont complètement hors de propos. PMD, d'autre part, est également en mesure de signaler des pratiques de codage douteuses et son résultat est généralement plus pertinent et utile.


49
+1 pour ajouter votre recommandation de FindBugs. Cependant, je ne suis pas du tout d'accord avec votre opinion sur Checkstyle, sauf si vous êtes un développeur solitaire avec votre propre style idiosyncratique. Pour les équipes, s'entendre sur un sous-ensemble raisonnable de règles communes, puis utiliser un outil automatisé comme Checkstyle pour les appliquer automatiquement aboutit à un code lisible par tous.
John Tobler

1
Bien qu'il ne soit pas parfait, FindBugs est de loin le meilleur. PMD et checkstyle vous orientent vers de véritables mauvaises pratiques. A éviter à tout prix sauf si vous savez très bien quels avertissements sont valables et lesquels ne le sont pas.
DPM

Curieusement, j'ai eu l'expérience exactement opposée avec PMD vs Checkstyle. PMD rapporte souvent des faux positifs si c'est quelque chose de checkstyle ou Findbugs n'a pas trouvé. 7 ans peuvent avoir beaucoup d'importance.
xenoterracide

38

Les deux logiciels sont utiles. Checkstyle vous aidera lors de votre programmation en vérifiant votre style de codage c'est à dire accolades, dénomination etc. Des choses simples mais très nombreuses!

PMD vous aidera en vérifiant des règles plus compliquées comme lors de la conception de vos classes, ou pour des problèmes plus spéciaux comme l'implémentation correcte de la fonction de clonage. Simplement, PMD vérifiera votre style de programmation

Cependant, les deux logiciels souffrent de règles similaires parfois mal expliquées. Avec une mauvaise configuration, vous pouvez vérifier les choses deux fois ou deux choses opposées à savoir "Supprimer les constructeurs inutiles" et "Toujours un constructeur".


10
Exactement. IMHO, ce sont 2 outils visant à faire des choses différentes, donc je ne suis pas sûr qu'ils soient même comparables. Si vous souhaitez appliquer un style de codage standard au sein d'une équipe de développement, utilisez Checkstyle. Si vous souhaitez analyser le code pour des problèmes de conception ou de mauvaises pratiques de codage, utilisez PMD.
aberrant80

24

Si nous en choisissons un, lequel devrions-nous utiliser et pourquoi?

Ces outils ne sont pas concurrents mais complémentaires et doivent être utilisés simultanément.

Le type de convention (Checkstyle) est le ciment qui permet aux gens de travailler ensemble et de libérer leur créativité au lieu de passer du temps et de l'énergie à comprendre un code incohérent.

Exemples de checkstyle:

  • Existe-t-il javadoc sur les méthodes publiques?
  • Le projet respecte-t-il les conventions de dénomination de Sun?
  • Le code est-il écrit dans un format cohérent?

tandis que PMD vous rappelle les mauvaises pratiques:

  • Attraper une exception sans rien faire
  • Avoir du code mort
  • Trop de méthodes complexes
  • Utilisation directe d'implémentations au lieu d'interfaces
  • Implémentation de la méthode hashcode () sans la méthode not equals (Object object)

source: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/


1
Je suis d'accord que Checkstyle, plus axé sur le format du code et oblige le développeur à suivre le "Code standard", mais il pourrait également détecter beaucoup de mauvaises pratiques, jetez un œil ici , et l'extension de Checkstyle est plus facile à développer, mais je suis d'accord qu'il a des limites et ne surmontera jamais PMD et FindBug.
Roman Ivanov

15

Nous utilisons à la fois:

  • Vérifiez le style pour vous assurer que tous les membres de l'équipe écrivent le code de la même manière
  • PMD pour trouver les zones de code problématiques et les prochaines cibles de refactoring

7

Si votre principal lieu d'utilisation est lors du développement dans eclipse, alors CodePro des instanciations sera le meilleur. Auparavant, c'était un outil commercial, mais maintenant Google a acheté des instanciations, donc CodePro analytix est maintenant gratuit.

Consultez http://code.google.com/javadevtools/download-codepro.html


7

Si vous avez examiné les listes de règles Checkstyle, PMD et Findbugs, vous avez vu que les trois fournissent des résultats précieux et que les trois se chevauchent dans une certaine mesure et apportent également leurs propres règles uniques à la table. C'est pourquoi des outils comme Sonar utilisent les trois.

Cela dit, Findbugs a les règles les plus spécifiques ou les plus spécifiques (par exemple "Attrapage douteux d'IllegalMonitorStateException" - à quelle fréquence êtes-vous susceptible de rencontrer cela?) Donc il est utilisable avec peu ou pas de configuration et ses avertissements doivent être pris au sérieux. Avec Checkstyle et PMD, les règles sont plus générales et liées au style, elles ne doivent donc être utilisées qu'avec des fichiers de configuration personnalisés pour éviter à l'équipe une avalanche de commentaires non pertinents ("Tab char on line 5", "Tab char on line 6", "Tab char on line 7" ... vous obtenez l'image). Ils fournissent également des outils puissants pour écrire vos propres règles avancées, par exemple la règle Checkstyle DescendentToken .

Lors de l'utilisation des trois (en particulier avec un outil comme Sonar), ils doivent tous être configurés séparément (prend au moins quelques jours pour couvrir toutes les règles) tout en faisant attention à éviter la duplication (les trois outils détectent que hashCode () a été remplacé et égal à () non, par exemple).

En résumé, si vous considérez que l'analyse de code statique est utile, rejeter la valeur fournie par l'un des trois n'a aucun sens, mais pour utiliser les trois, vous devez investir du temps pour les configurer afin de vous donner des commentaires utilisables.


6

Sonar (http://www.sonarsource.org/) est une plate-forme ouverte très utile pour gérer la qualité du code, et comprend Checkstyle, PMD, Findbugs et bien plus encore.

Cela indique également que les 3 outils ont le droit d'exister ...


5

Les deux outils sont configurables et peuvent faire à peu près les mêmes choses. Cela dit, si nous parlons de produits prêts à l'emploi, il y a beaucoup de chevauchement, mais il existe également des règles / contrôles distincts. Par exemple, Checkstyle a un meilleur support pour vérifier Javadoc et trouver des nombres magiques, pour n'en nommer que quelques-uns. De plus, Checkstyle a une fonction de "contrôle d'importation" qui ressemble à la fonctionnalité de Macker (je n'ai pas utilisé Macker).

S'il y a des choses qui sont importantes pour vous que Checkstyle fait directement et que PMD ne le fait pas, vous pouvez envisager une configuration Checkstyle minimale avec uniquement ces vérifications. Ensuite, mettez en place une politique que la configuration Checkstyle ne peut pas augmenter, supprimez simplement les vérifications lorsque vous implémentez des fonctionnalités similaires avec, par exemple, des règles PMD personnalisées.

Considérez également que si vous décidez que la fonction "contrôle d'importation" de Checkstyle couvre ce que vous vouliez de Macker, alors vous pouvez implémenter PMD / Checkstyle au lieu de PMD / Macker. Quoi qu'il en soit, il s'agit de deux outils, mais avec Checkstyle, vous obtiendrez ce que PMD ne fait pas directement «gratuitement».


5

Checkstyle et PMD sont tous deux bons pour vérifier les normes de codage et sont faciles à étendre. Mais PMD a des règles supplémentaires pour vérifier la complexité cyclomatique, la complexité de Npath, etc. qui vous permet d'écrire du code sain.

Un autre avantage de l'utilisation de PMD est CPD (Copy / Paste Detector) .Il détecte la duplication de code entre les projets et n'est pas limité à JAVA.Il fonctionne également pour JSP. Neal Ford a une bonne présentation sur Metrics Driven Agile Development , qui parle de nombreux outils utiles pour le développement Java / Java EE


4
Pour tous ceux qui liront ceci ... checkstyle a maintenant ces checkstyle.sourceforge.net/config_metrics.html checkstyle.sourceforge.net/config_duplicates.html
smp7d

4

Je trouve que Checkstyle et PMD sont les meilleurs pour appliquer les problèmes de style et les bogues de codage évidents simples. Bien que j'aie trouvé que j'aime utiliser Eclipse et tous les avertissements qu'il fournit mieux à cette fin. Nous appliquons les éléments en utilisant des préférences partagées et en les marquant comme des erreurs réelles. De cette façon, ils ne sont jamais enregistrés en premier lieu.

Ce que je recommanderais fortement et avec enthousiasme, c'est d'utiliser FindBugs. Parce qu'il fonctionne au niveau du bytecode, il peut vérifier des choses qui sont impossibles au niveau de la source. Bien qu'il crache sa juste part de jonques, il a trouvé de nombreux bogues réels et importants dans notre code.


4

Et 10 ans plus tard ... En 2018, je les utilise tous Checkstyle, PMD et FindBugs.

Commencez par FindBugs . Peut-être ajouter PMD et Checkstyle plus tard.

N'appliquez jamais aveuglément les règles par défaut !

Pas:

  • exécuter un outil avec des règles par défaut sur un projet qui contient beaucoup de code
  • adapter les règles à ce projet, commenter les règles inutiles avec quelques notes
  • se concentrer sur les règles des fruits à portée de main (NPE, contrôles des bûcherons, contrôles des ressources non fermées, ...)
  • effectuez quelques corrections pour les règles que vous trouvez utiles (une à la fois!)
  • faites ceci pour chaque outil mais pas tous à la fois!
  • répétez ce processus

Idéalement, chaque projet peut avoir des règles distinctes. J'aime exécuter les règles via la construction (via les plugins maven) et échouer sur les erreurs de règles une fois que je sais qu'un projet passe toutes les règles que j'ai définies. Cela oblige les développeurs à agir, car le reporting ne suffit pas . À partir de là, votre projet est pratiquement à l'épreuve des balles et vous pouvez même ajouter plus de règles plus tard et / ou écrire des règles personnalisées.


Pour info , SpotBugs est le "successeur spirituel de FindBugs" , et la documentation SpotBugs est plutôt bonne. Autant que je sache, FindBugs n'a pas été mis à jour depuis des années.
skomisa

Jamais entendu parler de SpotBugs, probablement parce que FindBugs + fbcontrib suffisait depuis longtemps, bon de savoir qu'il y a du remplacement
Christophe Roussy

Il y a une discussion à ce sujet ici: news.ycombinator.com/item?id=12885549
Christophe Roussy

Il convient également de noter que les outils ont tendance à avoir une sensibilité configurable. Par exemple, lorsque vous démarrez avec FindBugs / SpotBugs, vous devrez peut-être choisir un seuil élevé pour attraper uniquement les bogues les plus graves, puis abaisser le seuil à mesure que vous corrigez les choses.
ThrawnCA

@ThrawnCA oui mais même avec sensibilité: sur un grand projet, trop d'erreurs seront trouvées pour être corrigées dans un laps de temps raisonnable. Donc, ce que je fais à la place est d'ajouter une règle à la fois, en commençant par les fruits les plus bas comme la détection potentielle de NP, puis en passant aux règles comme les ressources non fermées.
Christophe Roussy

3

Un point que je n'ai pas vu jusqu'à présent est qu'il existe des plugins pour les IDE qui appliqueront les règles CheckStyle sur votre code, alors que les plugins PMD ne rapporteront que les violations. Par exemple, dans un projet multi-site sur plusieurs équipes de programmation, il est important de faire appliquer activement les normes, plutôt que de simplement en rendre compte.

Les deux outils ont des plugins disponibles pour IntelliJ, NetBeans et Eclipse (à mon avis, cela couvre la plupart des utilisations). Je ne suis pas aussi familier avec NetBeans, donc je ne peux que commenter IntelliJ et Eclipse.

Quoi qu'il en soit, les plugins PMD pour IntelliJ et Eclipse généreront des rapports à la demande sur les violations PMD dans la base de code du projet.

Les plugins CheckStyle, quant à eux, mettront en évidence les violations à la volée et peuvent (au moins pour IntelliJ, j'ai moins d'expérience avec Eclipse) être configurés pour convertir automatiquement certains problèmes (par exemple pour 'OneStatementPerLine', placeront CR-LF entre les instructions, pour 'NeedBraces', ajoutera des accolades là où elles sont manquantes, etc.). Évidemment, seules les violations les plus simples peuvent être automatiquement corrigées, mais cela reste une aide sur les projets hérités ou les projets situés sur plusieurs emplacements.

«À la demande» pour PMD signifie que le développeur doit délibérément décider d'exécuter le rapport. Alors que les violations de Checkstyle leur sont automatiquement signalées à mesure qu'elles se développent. Bien que PMD ne contient un ensemble de règles plus étendue, dans mon esprit le enforecement automatique / signalement des infractions à IDEs vaut les tracas de maintenir 2 ensembles de règles.

Donc, pour tous les projets sur lesquels je travaille, nous utilisons les deux outils, Checkstyle appliqué dans l'EDI, PMD signalé dans l'EDI, et tous deux rapportés et mesurés dans les builds (via Jenkins).


1
Il existe également des moyens de l'intégrer dans le build et de le faire échouer en cas de violation (avec maven par exemple). J'ai fait cela pour Checkstyle, PMD et FindBugs. Comme vous l'avez dit, les rapports ne suffisent pas.
Christophe Roussy

3

Jetez un œil à qulice-maven-plugin qui combine Checkstyle, PMD, FindBugs et quelques autres analyseurs statiques, et les pré-configure. La beauté de cette combinaison est que vous n'avez pas besoin de les configurer individuellement dans chaque projet:

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Comment le configurer pour obtenir un rapport (dans un format utilisable)? Maintenant, il ne le crache que sur la console même si je configure log4j. Je vois qu'il y a un rapport de bogue qui pourrait être lié, mais je ne suis pas sûr.
Adam Arold

Nous pensons la même chose, mais pour le résoudre, j'ai besoin qu'il soit mis en évidence dans mon code ou quelque chose de similaire. Au moins tu settings.jaras aidé.
Adam Arold

2

Je voudrais faire écho au commentaire selon lequel PMD est le produit le plus courant pour la vérification du style / convention Java. En ce qui concerne FindBugs, de nombreux groupes de développement commercial utilisent Coverity.


1

PMD est ce à quoi je trouve que plus de gens font référence. Checkstyle était ce à quoi les gens se référaient il y a 4 ans, mais je crois que PMD est maintenu de manière plus continue et avec quels autres IDE / plugins choisissent de travailler.


2
C'est vrai en 2008, mais aujourd'hui Checkstyle a pris beaucoup de vitesse.
barfuin

1

Je viens de commencer à utiliser Checkstyle et PMD. Pour moi, PMD est plus facile de créer des règles personnalisées pour des choses telles que s'il existe System.gc (), Runtime.gc (), tant que vous pouvez écrire la requête XPath, ce qui n'est pas non plus difficile du tout. Cependant, PMD ne m'a pas montré qu'il avait la fonction d'afficher le numéro de colonne. Donc, pour des choses comme vérifier les limites des colonnes. Vous voudrez peut-être utiliser Checkstyle.


-2

PMD est le meilleur outil par rapport aux styles de contrôle. Checkstyles peut ne pas avoir la capacité d'analyser le code alors que PMD offre de nombreuses fonctionnalités pour le faire! Offcourse PMD n'a pas publié de règles pour javadoc, commentaires, indentations, etc. Et d'ailleurs je prévois de mettre en œuvre ces règles ....... merci


Une bonne chose à propos du checkstyle est qu'il permet une règle flexible comme RegexpSingleline ...
Jigar Shah
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.