Introduction à CheckStyle

1. Vue d'ensemble

Checkstyle est un outil open source qui vérifie le code par rapport à un ensemble de règles configurables.

Dans ce tutoriel, nous allons voir comment intégrer Checkstyle dans un projet Java via Maven et en utilisant des plugins IDE.

Les plugins mentionnés dans les sections ci-dessous ne dépendent pas les uns des autres et peuvent être intégrés individuellement dans notre build ou nos IDE. Par exemple, le plugin Maven n'est pas nécessaire dans notre pom.xml pour exécuter les validations dans notre Eclipse IDE.

2. Plugin Checkstyle Maven

2.1. Configuration Maven

Pour ajouter Checkstyle à un projet, nous devons ajouter le plugin dans la section reporting d'un pom.xml :

   org.apache.maven.plugins maven-checkstyle-plugin 3.0.0  checkstyle.xml    

Ce plugin est livré avec deux vérifications prédéfinies, une vérification de style Sun et une vérification de style Google . La vérification par défaut d'un projet est sun_checks.xml.

Pour utiliser notre configuration personnalisée, nous pouvons spécifier notre fichier de configuration comme indiqué dans l'exemple ci-dessus. En utilisant cette configuration, le plugin lira maintenant notre configuration personnalisée au lieu de celle fournie par défaut.

La dernière version du plugin est disponible sur Maven Central.

2.2. Génération de rapports

Maintenant que notre plugin Maven est configuré, nous pouvons générer un rapport pour notre code en exécutant la commande mvn site . Une fois la construction terminée, le rapport est disponible dans le dossier cible / site sous le nom checkstyle.html.

Un rapport Checkstyle comprend trois parties principales:

Fichiers: Cette section du rapport nous fournit la liste des fichiers dans lesquels les violations se sont produites . Il nous montre également le décompte des violations par rapport à leur niveau de gravité. Voici à quoi ressemble la section des fichiers du rapport:

Règles: cette partie du rapport nous donne un aperçu des règles qui ont été utilisées pour vérifier les violations . Il montre la catégorie des règles, le nombre de violations et la gravité de ces violations. Voici un exemple du rapport qui montre la section des règles:

Détails: Enfin, la section des détails du rapport nous fournit les détails des violations qui se sont produites . Les détails fournis sont au niveau du numéro de ligne. Voici un exemple de section de détails du rapport:

2.3. Construire l'intégration

S'il est nécessaire d'avoir des contrôles stricts sur le style de codage, nous pouvons configurer le plugin de manière à ce que la construction échoue lorsque le code ne respecte pas les normes.

Nous faisons cela en ajoutant un objectif d'exécution à notre définition de plugin:

 org.apache.maven.plugins maven-checkstyle-plugin ${checkstyle-maven-plugin.version}  checkstyle.xml     check    

L' attribut configLocation définit le fichier de configuration auquel se référer pour les validations.

Dans notre cas, le fichier de configuration est checkstyle.xml. La vérification d' objectif mentionnée dans la section d'exécution demande au plugin de s'exécuter dans la phase de vérification de la construction et force un échec de construction lorsqu'une violation des normes de codage se produit.

Maintenant, si nous exécutons la commande mvn clean install , elle analysera les fichiers pour les violations et la compilation échouera si des violations sont trouvées.

Nous pouvons également exécuter uniquement l' objectif de vérification du plugin en utilisant mvn checkstyle: check, sans configurer l'objectif d'exécution. L'exécution de cette étape entraînera également un échec de construction en cas d'erreurs de validation.

3. Plug-in Eclipse

3.1. Configurations

Tout comme avec l'intégration Maven, Eclipse nous permet d'utiliser notre configuration personnalisée.

Pour importer notre configuration, allez dans Fenêtre -> Préférences -> Checkstyle. Dans la section Global Check Configurations , cliquez sur New.

Cela ouvrira un dialogue qui nous fournira des options pour spécifier notre fichier de configuration personnalisé.

3.2. Navigation dans les rapports

Maintenant que notre plugin est configuré, nous pouvons l'utiliser pour analyser notre code.

Pour vérifier le style de codage d'un projet, cliquez avec le bouton droit sur le projet dans l' explorateur de projet Eclipse et sélectionnez CheckStyle -> Vérifier le code avec Checkstyle.

Le plugin nous donnera des commentaires sur notre code Java dans l'éditeur de texte Eclipse. Il générera également le rapport de violation pour le projet qui est disponible sous forme de vue dans Eclipse.

Pour afficher le rapport de violation, accédez à Fenêtre -> Afficher la vue -> Autre et recherchez Checkstyle. Les options du graphique des violations et des violations doivent être affichées.

La sélection de l'une ou l'autre option nous donnera une représentation des violations regroupées par type. Voici le graphique à secteurs des violations pour un exemple de projet:

Cliquer sur une section du graphique à secteurs nous amènerait à la liste des violations réelles du code.

Alternativement, nous pouvons ouvrir la vue Problème d'Eclipse IDE et vérifier les problèmes signalés par le plugin.

Voici un exemple de vue du problème d'Eclipse IDE:

Cliquer sur l'un des avertissements nous amènera au code où la violation s'est produite.

4. Plug-in IntelliJ IDEA

4.1. Configuration

Comme Eclipse, IntelliJ IDEA nous permet également d'utiliser nos propres configurations personnalisées avec un projet.

Dans l'IDE, ouvrez Paramètres et recherchez Checkstyle. Une fenêtre s'affiche qui a la possibilité de sélectionner nos chèques. Cliquez sur le bouton + et une fenêtre s'ouvrira qui nous permettra de spécifier l'emplacement du fichier à utiliser.

Maintenant, nous sélectionnons un fichier XML de configuration et cliquons sur Suivant. Cela ouvrira la fenêtre précédente et affichera notre option de configuration personnalisée nouvellement ajoutée. Nous sélectionnons la nouvelle configuration et cliquons sur OK pour commencer à l'utiliser dans notre projet.

4.2. Navigation dans les rapports

Maintenant que notre plugin est configuré, utilisons-le pour vérifier les violations. Pour vérifier les violations d'un projet particulier, accédez à Analyser -> Inspecter le code.

Les résultats des inspections nous donneront une vue des violations dans la section Checkstyle. Voici un exemple de rapport:

Cliquez sur les violations pour accéder aux lignes exactes du fichier où les violations se sont produites.

5. Configuration du style de contrôle personnalisé

Dans la section de génération de rapport Maven (section 2.2), nous avons utilisé un fichier de configuration personnalisé pour effectuer nos propres vérifications de normes de codage.

Nous avons un moyen de créer notre propre fichier XML de configuration personnalisé si nous ne voulons pas utiliser les contrôles Google ou Sun intégrés.

Voici le fichier de configuration personnalisé utilisé pour les vérifications ci-dessus:

5.1. Définition DOCTYPE

La première ligne de la définition DOCTYPE est une partie importante du fichier et elle indique où télécharger la DTD afin que les configurations puissent être comprises par le système.

Si nous n'incluons pas cette définition dans notre fichier de configuration, ce ne sera pas un fichier de configuration valide.

5.2. Modules

Un fichier de configuration est principalement composé de modules. Un module a un nom d' attribut qui représente ce que fait le module. La valeur de l' attribut name correspond à une classe dans le code du plugin qui est exécutée lorsque le plugin est exécuté.

Découvrons les différents modules présents dans la config ci-dessus.

5.3. Détails du module

  • Checker: les modules sont structurés dans une arborescence qui a le module Checker à la racine. Ce module définit les propriétés héritées par tous les autres modules de la configuration.
  • TreeWalker: ce module vérifie les fichiers source Java individuels et définit les propriétés applicables à la vérification de ces fichiers.
  • EviterStarImport: Ce module définit une norme pour ne pas utiliser les importations Star dans notre code Java. Il a également une propriété qui demande au plugin de signaler la gravité de ces problèmes sous forme d'avertissement. Ainsi, chaque fois que de telles violations sont trouvées dans le code, un avertissement sera signalé contre elles.

Pour en savoir plus sur les configurations personnalisées, suivez ce lien.

6. Analyse du rapport pour le projet Spring-Rest

Dans cette section, nous allons faire la lumière sur une analyse effectuée par Checkstyle, en utilisant la configuration personnalisée créée dans la section 5 ci-dessus, sur le projet spring-rest disponible sur GitHub à titre d'exemple.

6.1. Génération de rapport de violation

Nous avons importé la configuration dans Eclipse IDE et voici le rapport de violation généré pour le projet:

Les avertissements rapportés ici indiquent que les importations de caractères génériques doivent être évitées dans le code. Nous avons deux fichiers qui ne sont pas conformes à cette norme. Lorsque nous cliquons sur l'avertissement, cela nous amène au fichier Java qui a la violation.

Voici comment le fichier HeavyResourceController.java affiche l'avertissement signalé:

6.2. Résolution des problèmes

L'utilisation d'importations Star n'est pas une bonne pratique en général car elle peut créer des conflits lorsque deux ou plusieurs packages contiennent la même classe.

À titre d'exemple, considérons la classe List, qui est disponible dans les packages java.util et java.awt . Si nous utilisons à la fois les importations de java.util . * Et java.awt. *, Notre compilateur ne parviendra pas à compiler le code, car List est disponible dans les deux packages.

Pour résoudre le problème mentionné ci-dessus, nous organisons les importations dans les deux fichiers et les enregistrons. Maintenant, lorsque nous exécutons à nouveau le plugin, nous ne voyons pas les violations et notre code suit maintenant les normes définies dans notre configuration personnalisée.

7. Conclusion

Dans cet article, nous avons couvert les bases de l'intégration de Checkstyle dans notre projet Java.

Nous avons appris qu'il s'agit d'un outil simple mais puissant, utilisé pour s'assurer que les développeurs respectent les normes de codage définies par l'organisation.

L'exemple de code que nous avons utilisé pour l'analyse statique est disponible à l'adresse over sur GitHub.