SonarQube remplace-t-il Checkstyle, PMD, FindBugs?

Nous travaillons sur un projet Web à partir de zéro et étudions les outils d’parsing de code statique suivants.

  • Conventions (Checkstyle)
  • Mauvaises pratiques (PMD)
  • Bugs potentiels (FindBugs)

Le projet est construit sur Maven. Au lieu d’utiliser plusieurs outils à cette fin, je cherchais une solution unique et flexible et je suis tombé sur SonarQube.

Est-il vrai que nous pouvons obtenir les résultats de Checkstyle, PMD et Findbugs avec SonarQube?

Sonar exécutera CheckStyle, FindBugs et PMD, ainsi que quelques autres “plugins” tels que Cobertura (couverture de code) par défaut pour les projets Java. La principale valeur ajoutée est toutefois le stockage de l’historique dans une firebase database. Vous pouvez alors voir la tendance . Améliorez-vous la base de code ou faites-vous le contraire? Seul un outil avec mémoire peut vous le dire.

Vous devez exécuter Sonar dans votre système CI pour que même les tâches qui prennent un certain temps (par exemple, CPD – détecteur de collage) puissent s’exécuter. Et vous aurez votre histoire. Alors qu’avec un plugin Eclipse, par exemple, vous détecterez les violations plus tôt – ce qui est bien , mais vous serez tenté de l’exécuter moins souvent si cela prend trop de temps ou de lancer moins de “plugins de qualité” sauter l’parsing de la couverture du code). Et vous n’aurez pas d’histoire.

De plus, Sonar génère des rapports visuels , style “Dashboard”. Ce qui le rend très facile à saisir. Avec Sonar dans Jenkins, vous pourrez montrer aux développeurs et à votre direction les effets du travail effectué sur la qualité de la base de code au cours des dernières semaines et des derniers mois.

Sonar utilise ces 3 outils en tant que plugins et agrège les données des trois donnant une valeur ajoutée en affichant des graphiques et autres à partir de ces outils. Ils sont donc complémentaires au sonar.

Oui et non. En plus des autres réponses.

SonarQube est actuellement sur le sharepoint désapprouver PMD, Checkstyle et Findbugs et d’utiliser leur propre technologie pour parsingr le code Java (appelé SonarJava ). Ils le font, car ils ne veulent pas passer leur temps à réparer, mettre à jour (ou attendre) ces bibliothèques (par exemple pour Java 8), qui utilisent par exemple des bibliothèques obsolètes.

Ils ont également obtenu un nouvel ensemble de plug-ins pour votre IDE personnel appelé SonarLint .

Sonar est génial, mais si vous voulez utiliser les outils mentionnés séparément et que vous avez toujours de jolis graphes, vous pouvez utiliser le plug-in Analysis Collector dans votre build Jenkins CI. Un léger avantage est que vous pouvez vérifier votre configuration PMD / Findbugs / Checkstyle dans votre SCM et l’intégrer à votre version de Maven, plutôt que de vous fier à un serveur Sonar distinct.

Sonar est beaucoup plus que ces seuls outils. Le plus grand avantage est l’interface graphique, qui vous permet de configurer n’importe quoi facilement. Les statistiques qu’il propose sont très détaillées (lignes de code, etc.). Et il offre même un excellent support pour la couverture des tests, etc. 🙂

Ici vous pouvez jeter un bon coup d’oeil: http://nemo.sonarsource.org/

Je voudrais quand même utiliser ces outils en plus du sonar car ils peuvent échouer à la construction de maven quand quelqu’un viole une règle. Où sonar est plus rétrospectif.

… quelques années plus tard: non, ce n’est pas le cas! SonarQube suppose de pouvoir couvrir toutes les règles avec son propre parsingur, mais il existe toujours des règles de PMD ou de CheckStyle non couvertes par SonarQube. Voir par exemple: PMD ReturnFromFinallyBlock.

Eh bien au moins depuis SonarQube 6.3+, il semble que Findbugs ne soit (actuellement) plus pris en charge en tant que plug-in. Sonarsource travaille sur le remplacement de règles Findbugs avec son propre plugin Java.

Ils ont même une liste pour le statut de remplacement de chaque règle ici: http://dist.sonarsource.com/reports/coverage/findbugs.html