Checkstyle vs PMD

Question

Nous introduisons des outils d'analyse statique dans le système de génération de notre produit Java. Nous utilisons Maven2 pour Checkstyle et L’intégration PMD est gratuite. Cependant, il semble que les fonctionnalités de ces deux outils se chevauchent beaucoup en termes d'application des règles de style de base.

Y at-il un avantage à utiliser les deux? Je ne veux pas maintenir 2 outils si on va travailler. Si nous en choisissons un, lequel devrions-nous utiliser et pourquoi?

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

Mise à jour: Le consensus semble être que le PMD est préféré au CheckStyle. Je ne vois pas de raison solide pour utiliser les deux et je ne souhaite pas conserver deux ensembles de fichiers de règles. Nous allons donc viser exclusivement la PMD. Nous allons également introduire FindBugs et peut-être éventuellement Macker pour appliquer les règles architecturales.

Answer 1

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 rapporte 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 s’agit quasiment que du style. D'après mon expérience, Checkstyle rendra compte d'une multitude de choses totalement hors de propos. De son côté, PMD est également capable de signaler des pratiques de codage douteuses et son résultat est généralement plus pertinent et utile.

Answer 2

Les deux logiciels sont utiles. Checkstyle vous aidera pendant votre programmation en vérifiant votre style de codage , par exemple les accolades, les noms, etc. Des choses simples mais très nombreuses!

PMD vous aidera en vérifiant des règles plus complexes, comme lors de la conception de vos classes, ou des problèmes plus spécifiques, tels que la mise en œuvre correcte de la fonction de clonage. PMD vérifiera simplement 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 deux ou deux choses opposées, à savoir "Supprimer les constructeurs inutiles". et "Toujours un constructeur".

Answer 3

  

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 utilisateurs de travailler ensemble et de libérer leur créativité au lieu de consacrer du temps et de l'énergie à la compréhension d'un code incohérent.

Exemples de styles de contrôle:

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

alors que PMD vous rappelle de mauvaises pratiques:

• Attraper une exception sans rien faire
• Ayant un 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 non égale (objet objet)

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

Answer 4

Nous utilisons les deux:

• Vérifiez le style pour vous assurer que tous les membres de l'équipe écrivent le code de manière similaire
• PMD pour rechercher les zones de code problématiques et les cibles de refactoring suivantes

Answer 5

Si votre principal lieu d’utilisation est le développement sous eclipse, alors CodePro d’Instantiations sera préférable. Auparavant, c’était un outil commercial, mais Google a maintenant acheté des instanciations, de sorte que CodePro analytix est gratuit.

Découvrez http://code.google.com/javadevtools/download-codepro. html

Answer 6

Si vous avez examiné les listes de règles Checkstyle, PMD et Findbugs, vous avez constaté que toutes les trois fournissent un résultat intéressant et qu'elles se chevauchent dans une certaine mesure, ainsi que leurs propres règles uniques. C’est pourquoi des outils tels que Sonar utilisent ces trois technologies.

Cela étant dit, Findbugs a les règles les plus spécifiques ou les niches (par exemple, "Capture douteuse de IllegalMonitorStateException" - combien de fois êtes-vous susceptible de le rencontrer?), de sorte qu'il est utilisable avec peu ou pas de configuration et que ses avertissements doivent être pris sérieusement. 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 ("Caractère de tabulation sur la ligne 5", "Caractère de tabulation sur la ligne 6" ;, "Caractère de tabulation à la ligne 7" ... vous obtenez la photo). Ils fournissent également des outils puissants pour écrire vos propres règles avancées, par exemple. la règle DescendentToken de Checkstyle.

Lorsque vous utilisez les trois (en particulier avec un outil comme Sonar), vous devez tous les configurer séparément (il faut au moins quelques jours pour couvrir toutes les règles) tout en veillant à éviter les doublons (les trois outils détectent ce hashCode ( ) a été remplacé et égal à () pas, par exemple).

En résumé, si vous estimez que l'analyse de code statique est intéressante, le rejet de la valeur fournie par l'une des trois n'a aucun sens, mais pour utiliser les trois, vous devez investir du temps pour les configurer afin de vous donner des informations exploitables.

Answer 7

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

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

Answer 8

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

Un autre avantage de l’utilisation de PMD est le CPD (Détecteur Copier / Coller). 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 au développement Java / Java EE

Answer 9

Je trouve que Checkstyle et PMD conviennent mieux à la résolution des problèmes de style et aux simples bogues de codage évidents. Bien que j’ai trouvé que j’aime utiliser Eclipse et tous les avertissements, il est préférable de le faire à cette fin. Nous appliquons des é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 vivement et avec enthousiasme est d’utiliser FindBugs. Comme il fonctionne au niveau du bytecode, il peut vérifier les choses 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.

Answer 10

Les deux outils sont configurables et peuvent faire à peu près les mêmes choses. Cela dit, si nous parlons de solutions prêtes à l'emploi, il y a beaucoup de chevauchements, mais il existe également des règles / contrôles distincts. Par exemple, Checkstyle prend davantage en charge la vérification de Javadoc et la recherche de nombres magiques, pour en nommer deux. En outre, Checkstyle a un "contrôle d'importation". fonctionnalité qui ressemble à la fonctionnalité de Macker (je n’ai pas utilisé Macker).

Si certains éléments importants pour vous, tels que Checkstyle, ne sont pas compatibles avec PMD, vous pouvez envisager une configuration Checkstyle minimale avec uniquement ces contrôles. Instaurez ensuite une stratégie selon laquelle la configuration Checkstyle ne peut pas croître, supprimez simplement les vérifications dès lors que vous implémentez une fonctionnalité similaire avec, par exemple, des règles PMD personnalisées.

Considérez également que si vous décidez que le style de contrôle " contrôle de l'importation " Cette fonctionnalité couvre ce que vous vouliez de Macker, vous pouvez alors implémenter PMD / Checkstyle au lieu de PMD / Macker. Quoi qu’il en soit, c’est deux outils, mais avec Checkstyle, vous obtiendrez ce que PMD ne fait pas d’usine "gratuitement".

Answer 11

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, tandis que les plugins PMD ne feront que signaler les violations. Par exemple, dans un projet multi-site impliquant plusieurs équipes de programmation, il est important d'appliquer activement les normes, plutôt que de simplement en rendre compte.

Les deux outils disposent de plug-ins disponibles pour IntelliJ, NetBeans et Eclipse (à mon avis, cela couvre la plupart des utilisations). Je ne connais pas aussi bien NetBeans, je ne peux donc que commenter IntelliJ et Eclipse.

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

D'autre part, les plugins CheckStyle mettront en évidence les violations à la volée et peuvent (du moins pour IntelliJ, j'ai moins d'expérience avec Eclipse) être configurés pour convertir automatiquement certains problèmes (par exemple, pour 'OneStatementPerLine', CR-LF entre les instructions, pour 'NeedBraces', ajoutera des accolades là où elles sont manquantes, etc.). Bien entendu, seules les violations simples peuvent être corrigées automatiquement, mais il s’agit toujours d’une aide pour les projets hérités, ou les projets situés sur plusieurs sites.

"Sur demande" pour PMD signifie que le développeur doit consciemment décider de générer le rapport. Les infractions Checkstyle leur sont automatiquement signalées à mesure qu’elles se développent. Bien que PMD contienne un ensemble de règles plus complet, dans mon esprit, l’application automatique des violations et le signalement des violations dans les IDE valent la peine de maintenir deux ensembles de règles.

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

Answer 12

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

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

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

Étapes:

• exécuter un outil avec des règles par défaut sur un projet comportant beaucoup de code
• adaptez les règles à ce projet, commentez les règles inutiles avec des notes
• concentrez-vous sur les règles du bas prix (NPE, contrôles d'enregistreur, contrôles de ressources non fermées, ...)
• corrigez quelques-unes des règles que vous jugez utiles (une à la fois!)
• faites cela pour chaque outil mais pas tous en même temps!
• répéter 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 en cas d'erreur de règle dès que je sais qu'un projet respecte toutes les règles que j'ai définies. Cela oblige les développeurs à prendre des mesures, car les rapports ne suffisent pas . À partir de là, votre projet est pratiquement à l'épreuve des balles et vous pouvez même ajouter ultérieurement des règles et / ou écrire des règles personnalisées.

Answer 13

Jetez un coup d’œil sur le plugin qulice-maven qui combine les styles Checkstyle, PMD, FindBugs et quelques autres analyseurs statiques et pré-configurés. L'intérêt de cette combinaison est qu'il n'est pas nécessaire 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>

Answer 14

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

Answer 15

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

Answer 16

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

Answer 17

PMD est le meilleur outil en comparaison avec les styles de contrôle. Checkstyles n’a peut-être pas la capacité d’analyser le code alors que PMD offre de nombreuses fonctionnalités pour le faire! Bien entendu, 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 ....... thanx