Code Linting

Aujourd'hui était une belle journée, car j'ai pu travailler sur l'intégration d'ESLint dans notre base de code ! Je suis un drôle de singe codé. J'apprécie les bonnes pratiques de codage telles que le peluchage, la documentation utilisateur/technique/produit, les tests, l'accessibilité et la sécurité. Ce sont des sujets qui sont généralement défavorisés par rapport à l'expédition du code fonctionnel, car le code peut fonctionner sans aucune des choses que j'ai énumérées comme mes passions en programmation. Mais si toutes ces pratiques sont mises en œuvre, le code sera rarement cassé (ou sera cassé) et est un code plus fiable. Pourquoi ne pas créer dès le départ un « code fonctionnel fiable ?

Pourquoi j'aime Linting ?

Linting vous aidera à détecter rapidement les erreurs courantes. Les règles de linting peuvent identifier de mauvaises pratiques de codage, afin que les développeurs ne les introduisent pas dans le projet. Le linting peut identifier quand utiliser const au lieu de let ou des variables shadow, par exemple.

Prévenir le mauvais code avec le peluchage vaut les nombreux sprints de débogage du mauvais code.

Mon défi

Nous avions une base de code existante à laquelle de nombreux développeurs ont contribué. Le code comportait plus de 5 000 violations de peluchage après avoir installé ESLint et généré un rapport. J'ai recherché les meilleures règles de peluchage à utiliser avec NextJS, TypeScript, A11y et JavaScript. Étant donné le grand nombre de violations, j'ai décidé de rechercher progressivement les erreurs. ESLint a une fonctionnalité de correction automatique, mais ne l'exécutez jamais sur une base de code préexistante et attendez-vous à ce qu'elle fonctionne. Non, non, pas de jeune. Il faut itérer !

J'ai réglé les règles critiques sur ❌ "erreur" et le reste sur "avertir" ou "off". Ensuite, j'ai réexécuté le rapport pour identifier ce qui devait être corrigé avant de déployer à nouveau notre code. Une fois que toutes les erreurs ont été corrigées manuellement et que le code peut être construit, j'ai exécuté notre test unitaire pour m'assurer que nous réussissions toujours ✅ tout. Un bon peluchage ne devrait jamais casser le code. Au mieux, le peluchage est destiné à soutenir le développeur. Aider les développeurs juniors à apprendre une meilleure façon d'écrire du code, car ils le doivent.

Une fois que toutes mes erreurs ont été identifiées et corrigées OU ignorées, nous pouvons alors déployer et savoir que notre code est aussi bon que nous pouvons l'obtenir "aujourd'hui". Maintenant que la base de code a été corrigée, nous pouvons utiliser "auto-magic-fix" à l'avenir et être sûrs qu'il a 50/50 de chances de corriger l'erreur de peluchage.

Mon apprentissage

Il semble qu'ESLint ait grandi ! Il ne prendra plus en charge certaines règles de formatage de code supplémentaires, qui devraient être gérées par une bibliothèque de formatage de code et non par une bibliothèque de linting. ESLint a rendu obsolète de nombreuses fonctionnalités à partir de la v9 et a migré la plupart, sinon la totalité, vers Stylistic !

J'utilise Prettier pour le formatage du code et Typescript prend en charge les indicateurs dans Stylistic, je suis donc resté avec ESLint v8.53.0 afin de pouvoir conserver le formatage de code supérieur d'ESLint. Mais je devrai éventuellement passer au 9, donc cela n'a fait que "lancer la boîte sur la route".

Bon codage !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!