Checkstyle vs PMD
Nous introduisons des outils d'analyse statique dans le système de construction de notre Java. Nous utilisons Maven2 donc Checkstyle et PMD l'intégration est gratuite, mais il semble qu'il y ait un grand chevauchement de fonctionnalités entre ces deux outils, en termes d'application des règles de style de base.
Y a-t-il un avantage à utiliser les deux? Je ne veux pas maintenir 2 outils si l'un fonctionnera. 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 PMD est préféré à CheckStyle. Je ne vois pas de raison solide d'utiliser les deux, et je ne veux pas conserver 2 ensembles de fichiers de règles, donc nous viserons probablement exclusivement PMD. Nous apporterons également FindBugs, et peut-être éventuellement Macker pour appliquer les règles architecturales.
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.
Quant à Checkstyle vs PMD, je n'utiliserais pas Checkstyle car il est à peu près uniquement concerné par le style. D'après mon expérience, Checkstyle fera rapport sur 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 ses résultats sont généralement plus pertinents et utiles.
Les deux logiciels sont utiles. Checkstyle vous aidera pendant votre programmation en vérifiant votre style de codage c.-à-d. 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 spéciaux 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 mal expliquées. Avec une mauvaise configuration, vous pouvez vérifier les choses deux ou deux choses opposées, à savoir "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 le code incohérent.
Exemples de style de contrôle:
- Y a-t-il du javadoc sur les méthodes publiques?
- Le projet suit-il les conventions de dénomination de Sun?
- Le code est-il écrit avec un format cohérent?
tandis que PMD vous rappelle les mauvaises pratiques:
- Attraper une exception sans rien faire
- Avoir un code mort
- Trop de méthodes complexes
- Utilisation directe des implémentations au lieu des 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/
Nous utilisons les deux:
- Checkstyle pour vous assurer que tout le monde dans l'équipe écrit du code de la même manière
- PMD pour trouver les zones de code problématiques et les prochaines cibles de refactoring
Si votre principal lieu d'utilisation est lors du développement dans Eclipse, alors CodePro from Instantiations sera le meilleur. Auparavant, c'était un outil commercial, mais maintenant Google a acheté Instantiations, donc CodePro analytix est gratuit 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 une sortie utile et 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 possède les règles les plus spécifiques ou les plus spécifiques (par exemple, "capture douteuse de IllegalMonitorStateException" - à quelle fréquence êtes-vous susceptible de rencontrer cela?), Il est donc 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 .
Lorsque vous utilisez les trois (en particulier avec un outil comme Sonar), tous doivent ê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é écrasé et égal () non, par exemple).
En résumé, si vous considérez l'analyse de code statique comme 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 fournir des commentaires utilisables.
Sonar (http://www.sonarsource.org/) est une plateforme 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 permettent d'écrire du code sain.
Un autre avantage de l'utilisation de PMD est CPD (Copy/Paste Detector) .Il découvre 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
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 chevauchements, 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 ne prête pas à l'emploi que PMD, vous pouvez envisager une configuration Checkstyle minimale avec uniquement ces vérifications. Instaurez ensuite une stratégie que la configuration Checkstyle ne peut pas augmenter, supprimez simplement les contrôles 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 de "contrôle d'importation" de Checkstyle couvre ce que vous vouliez de Macker, vous pouvez alors implémenter PMD/Checkstyle au lieu de PMD/Macker. Quoi qu'il en soit, ce sont deux outils, mais avec Checkstyle, vous obtiendrez tout ce que PMD ne fait pas prêt à l'emploi "gratuitement".
Je trouve que Checkstyle et PMD sont les meilleurs pour appliquer les problèmes de style et les simples bogues de codage évidents. Bien que j'ai trouvé que j'aime utiliser Eclipse et tous les avertissements qu'il fournit mieux à cette fin. Nous appliquons les 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 recommanderais fortement et avec enthousiasme, c'est d'utiliser FindBugs. Parce qu'il fonctionne au niveau du bytecode, il peut vérifier les choses impossibles au niveau source. Bien qu'il crache sa juste part de jonques, il a trouvé de nombreux bogues réels et importants dans notre code.
Un point que je n'ai pas vu jusqu'à présent est qu'il existe des plugins pour les IDE qui appliqueront les ensembles de règles CheckStyle sur votre code, tandis que les plugins PMD ne rapporteront 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 connais pas aussi bien NetBeans, je ne peux donc 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, 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 des accolades là où elles manquent, etc.). De toute évidence, seules les violations les plus simples peuvent être corrigées automatiquement, mais cela reste une aide pour les projets hérités ou les projets situés sur plusieurs emplacements.
"À la demande" pour PMD signifie que le développeur doit consciemment décider d'exécuter le rapport. Tandis que les violations de Checkstyle leur sont automatiquement signalées à mesure qu'elles se développent. Alors que PMD contient contient un ensemble de règles plus étendu, à mon avis, l'application/le signalement automatique des violations dans les IDE valent 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 rapporté et mesuré dans les versions (via Jenkins).
Et 10 ans plus tard ... En 2018, j'utilise tous Checkstyle, PMD et FindBugs.
Commencez par FindBugs. Ajoutez peut-être 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 faibles (NPE, vérifications des enregistreurs, vérifications des ressources non fermées, ...)
- effectuez quelques corrections pour les règles que vous trouvez 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 build (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 les rapports ne suffisent pas. À partir de ce moment, 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.
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>
Je voudrais faire écho au commentaire selon lequel PMD est le produit le plus récent pour Java vérification de style/convention. 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 System.gc (), Runtime.gc (), tant que vous pouvez écrire la requête XPath, ce qui n'est pas du tout difficile. Cependant, PMD ne m'a pas montré qu'il avait la fonctionnalité d'afficher le numéro de colonne. Donc, pour des choses comme vérifier les limites des colonnes. Vous voudrez peut-être 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 pense que PMD est maintenu de manière plus continue et avec quels autres IDE/plugins choisissent de travailler.