Écrire vos propres règles de code

Lorsque le développement du projet atteint une certaine étape, les ressources doivent être investies dans la construction d'un mécanisme de protection du code. Cette opportunité est difficile à définir avec précision. Évitez l'optimisation prématurée et évitez également l'optimisation trop tardive.

Certains outils sont très faciles à mettre en œuvre et sont généralement disponibles au début du projet. Par exemple, l'outil de formatage de code plus joli peut maintenir les spécifications de code en temps réel. Il existe également de nombreux outils similaires qui peuvent être utilisés directement pendant le processus d'encodage, tels que l'accessibilité, la compatibilité, la vérification du code de sécurité, etc. WebHint intègre un grand nombre de ces outils, ce qui vaut la peine d'essayer.

Il existe également des outils qui doivent écrire plus de code pour protéger votre code. Le test en est une partie importante et peut même être réglé pour s'exécuter pendant le codage. Le test garantit que le code s'exécute comme prévu et a donc une grande valeur.

Cet article se concentre sur la protection du code en écrivant plus de code, mais ce n'est pas un test traditionnel, mais une règle de vérification de code personnalisée. Récemment, je suis tombé sur deux articles sur les règles de vérification des code personnalisées:

• "Comment rédiger des règles Eslint personnalisées" par Benedict Quinn
• Les "règles de Stylelint personnalisées d'Omri Lavi - écrivez votre première règle"

J'utilise principalement Eslint et Stylelint dans la base de code. Mais il convient de noter que j'ai constaté que le processus d'écriture de règles personnalisés de ces deux outils est assez compliqué. Vous devez comprendre l'arbre de syntaxe abstrait (AST). Ceci est complètement différent d'une simple déclaration comme if (rules.find.selector.startsWith("old")) throw("Deprecated selector.")

Cela me rappelle une question intéressante:

Notre équipe maintient un ancien projet et espère supprimer de nombreux vieux sélecteurs CSS problématiques. Par exemple, quelqu'un a ouvert un fichier HTML et a vu un élément avec une classe .ui-fresh\_\_selector deprecated-selector .

La première chose qui me vient à l'esprit est d'écrire une règle de stylelint personnalisée qui recherche des sélecteurs obsolètes connus de l'équipe et émettre des avertissements. Mais malheureusement, Stylelint est utilisé pour vérifier CSS, et le principal problème ici semble être HTML. Je sais que l'inspecteur HTML peut écrire des règles personnalisées, mais c'est un peu obsolète, donc je ne sais pas si cela réussira.

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!