Contrôler la qualité de ses projets avec Sonar
Date de publication : 13/09/2008 , Date de mise à jour : 13/08/2009
IV. Les outils externes
IV-A. Checkstyle
IV-B. PMD
IV-C. JavaNCSS
IV-D. Sonar Squid
IV-E. Cobertura
IV. Les outils externes
Comme nous l'avons vu dans le chapitre précédent, Sonar s'appuie sur différents outils pour évaluer la qualité du code d'un projet.
Ces outils sont les suivants :
* JavaNCSS a été remplacé par Sonar-Squid depuis la version 1.9 de Sonar.
** Clover n'est utilisé que si le fichier de licence est trouvé.
Dans le cas contraire, c'est Cobertura qui sera utilisé.
IV-A. Checkstyle
Checkstyle est une aide précieuse pour les développeurs afin de leur faire respecter des standards de codage précis.
On y retrouve une liste assez complète de règles paramétrables (environ 130 règles) permettant de valider à peu près n'importe quel type de standard.
On pourra ainsi vérifier que les lignes n'excèdent pas une certaine longueur, que la Javadoc est bien présente, que les standards de nommage sont bien respectés, etc.
Checkstyle permet aussi d'améliorer l'écriture et la qualité de son propre code, en indiquant par exemple quelles expressions peuvent être simplifiées, quels blocs peuvent être supprimés, quelle classe doit être déclarée finale, etc.
La liste complète des quelques 130 règles disponibles sur Checkstyle se trouve
ici.
Sonar propose par défaut deux types de configuration Checkstyle : celle des règles définies par Sun, et celle des règles définies par Hortis.
Il est toutefois possible de lui demander d'intégrer ses propres règles de codage.
Pour cela, il suffit de se connecter en tant qu'administrateur, puis de cliquer sur "Coding Rules", puis de choisir "Create profile".
Sur l'image précédente, on voit que Sonar nous demande le nom de ce nouveau profil, ainsi que les fichiers XML de Checkstyle et de PMD.
En lui fournissant ces fichiers, on crée un nouveau profil qu'il faudra alors activer afin qu'il soit pris en compte pour les prochaines analyses.
On voit sur les captures précédentes que Sonar distingue les règles Checkstyle selon plusieurs catégories :
| Catégorie |
Description |
| Efficiency |
Liste des règles permettant d'améliorer l'efficacité du code. |
| Maintainability |
Liste des règles permettant d'améliorer la maintenabilité du code. |
| Portability |
Liste des règles permettant d'améliorer la portabilité du code. |
| Reliability |
Liste des règles permettant d'améliorer la fiabilité du code. |
| Usability |
Liste des règles permettant d'améliorer l'utilisabilité du code. |
Ces catégories sont définies par la
norme ISO 9126 qui permet de modéliser la qualité d'un logiciel informatique.
Concrètement, Sonar classe chacune des règles Checkstyle dans l'une ou l'autre de ces catégories.
Ainsi, la règle du calcul de la complexité cyclomatique (déterminant la complexité d'une méthode) sera placée dans la catégorie de la Maintenabilité, tandis que les règles de vérification de nommage seront listées dans la catégorie d'Utilisabilité.
Il est possible de connaître les règles activées en cliquant sur un profil :
Cette capture montre que pour chaque règle de codage, Sonar indique si elle est obligatoire, optionnelle ou inactive, indique de quel plugin elle émane (PMD ou Checkstyle), et précise enfin la catégorie à laquelle elle appartient.
Il n'est pour l'instant pas possible de ventiler soi-même les différentes règles au sein de ces catégories, mais cela pourra le devenir dans les versions futures de Sonar.
IV-B. PMD
PMD va scanner le code Java à la recherche de problèmes potentiels, tels que :
- Bugs possibles, blocs de code vides (try ... catch, switch).
- Code "mort", non utilisé (essentiellement des méthodes privées, ou des paramètres).
- Expressions trop lourdes, mauvaises utilisations des opérateurs de boucles.
- Code dupliqué, "erreurs de copier-coller"...
A l'instar de Checkstyle, Sonar va placer les différentes règles PMD dans les cinq catégories définies au chapitre précédent.
IV-C. JavaNCSS
JavaNCSS nous offre de nombreuses statistiques sur un projet Java, comme par exemple :
- Le nombre de packages présents dans le projet.
- Le nombre de classes Java.
- Le nombre de méthodes.
- Lignes de code (en considérant, ou non, les commentaires).
- Complexité cyclomatique.
- ...
JavaNCSS étant quelque peu vieillissant, l'équipe de Sonar a décidé de développer un remplaçant : SonarSquid.
Ce dernier comble un certain nombre de lacunes du premier.
IV-D. Sonar Squid
JavaNCSS ne permettait pas d'accéder à certaines métriques, des spécificités des dernières versions du langage Java n'étant pas supportées, l'équipe de Sonar a décidé de développer son propre outil, Sonar Squid.
Sonar Squid est partie intégrante de Sonar.
Attention, si vous utilisiez une version de Sonar antérieure ou égale à 1.8 et que vous migrez vers une version plus récente, il est possible que certaines statistiques évoluent un peu "bizarrement".
Cela est dû,
comme l'explique Freddy Mallet sur le blog de Sonar, au remplacement de JavaNCSS par SonarSquid, ce dernier corrigeant certaines lacunes du premier...
IV-E. Cobertura
Cobertura permet de calculer le taux de couverture du code par les tests unitaires.
C'est un indicateur extrêmement utile pour déterminer avec précision quelles parties de l'application ne sont pas suffisamment testées.
Sonar propose d'obtenir une vision au niveau d'un projet, d'un package, d'une classe ou d'une méthode de cette couverture de test.
Il est à noter que Cobertura peut être remplacé par l'outil
Clover d'Atlassian.
Etant donné qu'il s'agit d'un logiciel commercial, Sonar n'activera les rapports Clover que s'il trouve la licence d'utilisation de cet outil.
Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur.
La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
