Un correcteur automatique qui relit chaque ligne de code avant même qu’elle ne s’exécute, pour signaler une faute de frappe, une variable inutilisée ou une pratique risquée : voilà le rôle d’un linter dans le quotidien d’un développeur.
Deux linters courants sur un projet WordPress
Côté PHP, PHP_CodeSniffer accompagné du standard WordPress Coding Standards vérifie qu’un thème ou plugin respecte les conventions officielles du projet (indentation, nommage des fonctions, échappement des données). Côté JavaScript, ESLint, souvent configuré via @wordpress/eslint-plugin, applique les mêmes exigences de rigueur aux blocs Gutenberg et aux scripts d’un thème.
Exemple
vendor/bin/phpcs --standard=WordPress mon-plugin.php
FILE: mon-plugin.php
----------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------
12 | ERROR | Detected usage of a possibly undefined variable $titreLe linter n’exécute jamais réellement le fichier : il l’analyse statiquement et remonte une liste d’avertissements ou d’erreurs à corriger avant de committer.
À ne pas confondre avec un test automatisé
- Un linter vérifie la forme et certaines pratiques du code ; un test automatisé vérifie que le comportement réel du programme correspond à ce qui est attendu. Les deux sont complémentaires, pas interchangeables.
- La plupart des linters proposent un mode de correction automatique (
--fixou équivalent) pour les problèmes purement stylistiques, en laissant les erreurs de logique à corriger manuellement. - Intégrer un linter directement dans l’éditeur de code offre un retour immédiat, plus utile qu’une exécution tardive uniquement lors de l’intégration continue.