Introduction à CheckStyle

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

This plugin comes with two predefined checks, a Sun-style check, and a Google-style check. La vérification par défaut d'un projet estsun_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 va maintenant lire notre configuration personnalisée à la place de celle par défaut fournie.

La dernière version du plugin peut être trouvée surMaven Central.

Maintenant que notre plugin Maven est configuré, nous pouvons générer un rapport pour notre code en exécutant la commandemvn site. Once the build finishes, the report is available in the target/site folder under the name checkstyle.html.

Un rapport Checkstyle comporte trois parties principales:

Files: Cette section du rapport nous fournitthe list of files in which the violations have happened. Il nous montre également les comptes des violations par rapport à leur niveau de gravité. Voici à quoi ressemble la section fichiers du rapport:

Rules: Cette partie du rapport nous donne unoverview of the rules that were used to check for violations. Il montre la catégorie des règles, le nombre de violations et la gravité de ces violations. Voici un exemple du rapport contenant la section des règles:

Details: Enfin, la section détails du rapport nous fournit lesdetails of the violations that have happened. Les détails fournis sont au niveau du numéro de ligne. Voici un exemple de section de détails du rapport:

S'il est nécessaire de vérifier rigoureusement le style de codage,we can configure the plugin in such a way that the build fails when the code doesn’t adhere to the standards.

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

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

Dans notre cas, le fichier de configuration estcheckstyle.xml. L'objectifcheck mentionné dans la section 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 commandemvn clean install, elle analysera les fichiers pour les violations et la construction échouera si des violations sont trouvées.

Nous pouvons également exécuter uniquement l'objectifcheck du plugin en utilisantmvn checkstyle:check, sans configurer l'objectif d'exécution. L'exécution de cette étape entraînera également un échec de la génération en cas d'erreur de validation.

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

Pour importer notre configuration, allez dansWindow → Preferences → Checkstyle. Dans la sectionGlobal Check Configurations, cliquez surNew.

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

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 lesEclipse Project Explorer et sélectionnezCheckStyle → Check Code with Checkstyle.

The plugin will give us feedback on our Java code within the Eclipse, text editor. Cela 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 àWindow → Show View → Other et recherchez Checkstyle. Les options pourViolations etViolations Chart doivent être affichées.

En sélectionnant l'une ou l'autre option, vous obtiendrez 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 vueProblem de l'IDE Eclipse et vérifier les problèmes signalés par le plugin.

Voici un exemple de vue problématique de l'EDI Eclipse:

En cliquant sur l'un des avertissements nous mènera au code où la violation a eu lieu.

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

Dans l'EDI, ouvrez Paramètres et recherchez Checkstyle. Une fenêtre est affichée qui a la possibilité de sélectionner nos contrôles. 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 cliquez sur Suivant. Cela ouvrira la fenêtre précédente et montrera notre option de configuration personnalisée nouvellement ajoutée. Nous sélectionnons la nouvelle configuration et cliquez sur OK pour commencer à l'utiliser dans notre projet.

Maintenant que notre plug-in est configuré, utilisons-le pour vérifier les violations. Pour vérifier les violations d'un projet particulier, accédez àAnalyze → Inspect Code.

The Inspections Results will give us a view of the violations under the Checkstyle section. Voici un exemple de rapport:

En cliquant sur les violations nous amènera aux lignes exactes du dossier où les violations ont eu lieu.

La première ligne du i.e. La définition DOCTYPE est une partie importante du fichier et 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.

Un fichier de configuration est principalement composé de modules. A module has an attribute name which represents what the module does. La valeur de l’attributname 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 configuration ci-dessus.

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

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

Les avertissements signalés ici indiquent qu'il faut éviter les importations avec des caractères génériques dans le code. Nous avons deux fichiers qui ne sont pas conformes à cette norme. Lorsque nous cliquons sur l'avertissement, cela nous mène au fichier Java qui contient la violation.

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

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

À titre d'exemple, considérons la classeList, dontis est disponible dans les packagesjava.util etjava.awt tous les deux. Si nous utilisons à la fois les importations dejava.util. * Etjava.awt.*, notre compilateur ne parviendra pas à compiler le code, carList est disponible dans les deux packages.

To resolve the issue mentioned above we organize the imports in both files and save them. Maintenant, lorsque nous exécutons à nouveau le plugin, nous ne voyons pas les violations et notre code suit désormais les normes définies dans notre configuration personnalisée.