Checkstyle vs PMD

Les Deux logiciels sont utiles. Checkstyle vous aidera pendant votre programmation en vérifiant votre Style de codage c'est-à-dire accolades, nommage, 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 particuliers comme l'implémentation correcte de la fonction clone. Simplement, PMD vérifiera votre Style de programmation

Cependant, les deux logiciels souffrent de règles similaires parfois mauvaises expliquer. Avec une mauvaise configuration, vous pouvez vérifier les choses deux fois ou deux choses opposées, c'est-à-dire "supprimer les constructeurs inutiles" et "toujours un constructeur".

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 la colle 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.

Checkstyle exemples:

• y a-t-il javadoc sur les méthodes publiques ?
• le projet suit-Il Sun conventions de nommage ?
• le code est-il écrit avec un format cohérent ?

Alors que PMD vous rappelle les mauvaises pratiques:

• Attraper une exception sans rien faire
• ayant un code mort
• trop de méthodes complexes
• utilisation directe des implémentations au lieu des interfaces
• implémenter la méthode hashcode () sans le not equals (Object object) méthode

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

Nous utilisons les deux:

• Checkstyle pour vous assurer que tout le monde dans l'équipe écrire du code dans un maner similaire
• PMD pour trouver les zones de code problématiques et les cibles de refactoring suivantes

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

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

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 tous les trois.

Cela dit, Findbugs a les règles les plus spécifiques ou les plus spécifiques (par exemple "capture douteuse D'IllegalMonitorStateException" - à quelle fréquence Êtes-vous susceptible de rencontrer cela?) donc, il est utilisable avec peu ou pas de configuration et ses avertissements devraient ê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.

Lorsque vous utilisez les trois (en particulier avec un outil comme Sonar), tous doit être configuré 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 equals () pas, par exemple).

En résumé, si vous considérez l'analyse de code statique comme précieuse, rejeter la valeur de l'une des trois fournit n'a aucun sens, mais pour utiliser les trois, vous devez investir du temps pour les configurer pour vous donner un retour utilisable.

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...

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é 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 contraint de JAVA.It fonctionne aussi pour JSP. Neal Ford a une bonne présentation sur Métriques Poussé de Développement Agile, qui parle de nombreux outils qui sont utiles pour le développement Java/Java EE

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'ai trouvé que J'aime utiliser Eclipse et tous les Avertissements qu'il fournit mieux à cet effet. Nous appliquons des choses 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 recommande fortement et avec enthousiasme est d'utiliser FindBugs. Parce que cela fonctionne au niveau du bytecode il peut vérifier les choses qui sont impossible au niveau de la source. Bien qu'il recrache sa juste part de jonques, il a trouvé de nombreux bugs réels et importants dans notre code.

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

S'il y a des choses qui sont important pour vous que Checkstyle ne soit pas prêt à l'emploi que PMD ne le fait pas, vous pouvez envisager une configuration minimale de Checkstyle avec seulement ces vérifications. Ensuite, instituez une stratégie que la configuration Checkstyle ne peut pas développer, 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 fonctionnalité Checkstyle "import control" couvre ce que vous vouliez de Macker, vous pouvez implémenter PMD/Checkstyle au lieu de PMD/Macker. De toute façon, ce sont deux outils, mais avec Checkstyle, vous obtiendrez ce que PMD ne fait pas "GRATUITEMENT"."

Un point que je n'ai pas vu jusqu'à présent est qu'il existe des plugins pour les IDE qui appliqueront les jeux de règles CheckStyle sur votre code, alors que les plugins PMD ne signaleront que les violations. Par exemple, dans un projet multi-sites sur plusieurs équipes de programmation, il est important d'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 ne peut que commentez 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, d'autre part, 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', placera CR-LF entre les instructions, pour 'NeedBraces', ajoutera accolades où ils sont manquants, etc.). De toute évidence, seules les violations les plus simples peuvent être automatiquement corrigées, mais c'est toujours 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écider consciemment d'exécuter le rapport. Alors que les violations de Checkstyle leur sont automatiquement signalées à mesure qu'elles se développent. Alors que PMD contient un ensemble de règles plus étendu, dans mon esprit l'enforecement/reporting automatique des violations dans IDEs vaut la peine 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'IDE, PMD signalé dans L'IDE, et les deux signalés et mesurés dans les builds (via Jenkins).

Jetez un oeil à qulice-maven-plugin {[3] } qui combine ensemble 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 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>

Et 10 ans plus tard ... En 2018, j'utilise tous Checkstyle, PMD et FindBugs.

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

Ne jamais appliquer aveuglément les règles par défaut !

Étapes:

• exécutez un outil avec les règles par défaut sur un projet qui a beaucoup de code
• adaptez les règles à ce projet, commentez les règles inutiles avec quelques notes
• se concentrer sur les règles de fruits à faible pendaison (NPE, contrôles d'enregistreur, contrôles de ressources non fermés, ...)
• effectuez quelques corrections pour les règles que vous trouvez valables (une à la fois !)
• faites ceci pour chaque outil mais pas tous en même temps !
• 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ègle 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 les rapports ne suffisent pas . À partir de ce point sur votre projet est à peu près à l'épreuve des balles et vous pouvez même ajouter plus de règles plus tard et / ou écrire des règles personnalisées.

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

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 un système.gc(), la durée d'Exécution.gc (), tant que vous pouvez écrire la requête XPath qui n'est pas non plus difficile du tout. Cependant, PMD ne m'a pas montré qu'il a la fonctionnalité pour afficher le numéro de colonne. Donc, pour des choses comme vérifier les limites des colonnes. Vous pourriez vouloir utiliser Checkstyle.

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

PMD est le meilleur outil lors de la comparaison avec checkstyles. 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 et etc. Et en passant, je prévois de mettre en œuvre ces règles.......merci