Un linter bien configuré est le premier niveau de code review automatique. Il libère les relecteurs humains des discussions de style pour se concentrer sur l'architecture et la logique.
Le débat sur les espaces versus les tabulations, sur le point-virgule en JavaScript, sur le placement des accolades en Java — ces discussions consomment un temps précieux en code review et génèrent des frictions inutiles. Les linters et formateurs de code règlent ces questions une bonne fois pour toutes, en automatique. Le code est soit conforme, soit non-compilable. Plus de débats.
ESLint est le standard de facto pour JavaScript et TypeScript. Il combine vérification stylistique et détection d'erreurs potentielles : variables non utilisées, dépendances manquantes dans les hooks React, imports non résolus. Prettier est son complément naturel pour le formatage pur : il reformate automatiquement le code à la sauvegarde, sans discussion possible. Côté Java, Checkstyle vérifie les conventions de nommage et de structure, PMD détecte les patterns problématiques, et SpotBugs (successeur de FindBugs) analyse le bytecode pour détecter des bugs potentiels.
La clé du succès est l'intégration dans le workflow développeur. Un linter qui ne tourne que dans la CI décourage : les erreurs remontent trop tard. Il doit tourner à la sauvegarde (via l'éditeur), au commit (via un hook pre-commit avec Husky) et dans la CI comme filet final. Un linter configuré mais ignoré n'a aucune valeur — c'est l'adhésion de toute l'équipe qui crée la valeur, pas l'outil lui-même.
- ESLint + Prettier pour JS/TS, Checkstyle + SpotBugs pour Java
- Intégrez le linting à la sauvegarde dans votre IDE
- Ajoutez un hook pre-commit via Husky pour bloquer les violations
- Faites valider la CI en dernier filet de sécurité