Il y a quelque temps, j’aide un développeur junior, qui a un problème apparent sur son code, à découvrir ce qui ne va pas. Il a installé une charpie et téléchargé (Dieu sait pourquoi) un dictionnaire personnalisé pour elle. J’ai préparé un petit environnement de test et lui ai montré la différence entre les différents tests, à différents points et certaines limitations de chacun (sur ce petit environnement).
récemment, je parlais de tester avec un collègue et je me suis souvenu de cette anecdote et je me suis dit d’écrire un post à ce sujet car cela pourrait être intéressant pour beaucoup.,
qu’est-ce que les peluches?
Linting est la vérification automatisée de votre code source pour les erreurs programmatiques et stylistiques. Cela se fait à l’aide d’un outil lint (alias linter). Un outil lint est un analyseur de code statique de base.
le terme linting provient à l’origine d’un utilitaire Unix pour C. Il existe aujourd’hui de nombreux linters de code disponibles pour différents langages de programmation.
la programmation Lint est un type de contrôle automatisé. Cela peut se produire au début du développement, avant les révisions et les tests de code. En effet, les vérifications de code automatisées rendent les processus de révision et de test de code plus efficaces., Et ils libèrent vos développeurs de se concentrer sur les bonnes choses.
de nombreux outils de test automatisés tirent parti d’un linter intégré pour générer des erreurs, définir un score sur la qualité du code et bloquer la compilation ou une étape de déploiement si ce score est inférieur à celui souhaité (automatiquement ou en suspendant le processus en lançant une notification pour vérifier manuellement si ces « erreurs » doivent être corrigées ou non).
à quoi est destiné?
Linting est destiné à réduire les erreurs et améliorer la qualité globale du code devs, accélérer le développement et réduire les coûts en trouvant les erreurs plus tôt.,
quand utiliser le logiciel Lint?
Si cela est nouveau pour vous, vous pouvez être un peu hype avec lints à ce stade, mais ils ne sont pas un outil de programmation. Un lint est simplement un script »scrapper » /lecteur de fichiers avec un fichier (généralement un JSON ou xml) avec des règles prédéfinies (ou personnalisées) sur la façon dont le code doit ressembler. En fait, leses ont un Lint intégré qui vous lancera une erreur (c’est-à-dire si vous appelez une méthode inexistante, ou si vous essayez d’ajouter une valeur de chaîne dans une variable entière) ou un avertissement (c’est-à-dire, si vous déclarez une variable dans un conditionnel et que vous retournez cette variable à la fin de votre méthode). Mais je ne parle pas de la charpie de code intégrée, car ces linters sont « doux » et permissifs, sinon beaucoup de gens n’utiliseront pas Ceses, nous verrons pourquoi plus tard.
Vous pouvez utiliser un Lint spécifique si vous rentrez dans ces instructions:
lorsque vous utilisez des langages de programmation interprétés.
certaines langues sont mieux adaptées au linting de code que d’autres. PHP, Python et JavaScript sont des langages interprétés, cela signifie qu’ils n’ont pas de phase de compilation*., Ainsi, l’utilisation du logiciel lint est efficace pour assurer un style de codage cohérent et résoudre les erreurs de codage de base dans ces cas.
mais, en ce qui concerne les langages compilés, tels que C et c++, l’utilisation du logiciel lint pourrait ne pas suffire. C et c++ sont complexes et peuvent nécessiter une analyse de code plus avancée.
* vous criez peut-être que je compile JavaScript! mais c’est en fait pas vrai. De nos jours, sur front end, nous utilisons des outils comme les bundlers, en ajoutant des outils javascript qui passent notre js par certaines phases telles que minify, ugglify, ofuscate. Certains de ces outils suppriment également le code inutilisé sur sa sortie., Mais rien de tout cela ne signifie que vous compilez javascript, car la sortie sera un .fichier JS de toute façon; pas de bytecode, pas d’assembleur.
Il est vrai que vous pouvez convertir javascript en assembly web mais ce n’est pas un chemin direct de l’un à l’autre; vous devez convertir votre js en quelque chose de « compilable » tel code C, puis le compiler en assembly web.
lorsque vous utilisez des règles Standard
c’est une déclaration un peu délicate., Sur un langage de programmation, vous ne pourrez pas utiliser quelque chose qui n’est pas intégré à votre langage de programmation (ce n’est pas vrai du tout, car vous pouvez ajouter des bibliothèques ou lancer des commandes système à partir de langages de programmation, mais de toute façon, Lint n’a rien à voir avec cela…)
quelles sont les règles Standard?
L’utilisation d’un framework conviendra bien ici, vous devez utiliser des méthodes intégrées au framework pour atteindre la sortie souhaitée.
parfois, les règles standard signifient code à la mode., Ces méthodologies et solutions de contournement que la communauté répète comme un mantra jusqu’à ce qu’elle trouve un autre moyen à la mode d’atteindre la cible d’une tâche donnée, ou jusqu’à ce que quelqu’un avec une répercussion publique dise à la communauté « Hé, j’analysais ces solutions de contournement et je trouve qu’il existe une meilleure
lorsque vos besoins sont basiques
Les outils Lint sont parfaits pour l’analyse de base. Mais si vous avez besoin d’une analyse plus sophistiquée, vous devez chercher ailleurs (outils de test automatisés et développement piloté par les tests).
Où dois-je voir une charpie?
1., Sur les tests automatisés (nous les appelons automatisés car ils s’exécutent automatiquement mais quelqu’un doit coder le test pour chaque cas d’utilisation sur une application) tels que Cypress, vous pouvez ajouter une peluche pour marquer la qualité du code.
cela peut s’exécuter pendant le temps de développement (lorsque le développeur appuie sur le bouton test) ou probablement lors de la phase de déploiement. Par exemple, lorsque vous poussez quelque chose dans la branche principale, cela peut être un déclencheur pour augmenter les tests, y compris la charpie, et bloquer le déploiement (et vous blâmer) si vous avez fait quelque chose de mal, alors vous devrez réparer ou trouver le bogue (cela ne signifie pas que c’est de votre faute., Je pourrais pousser une API qui fait planter votre client en recevant des valeurs inattendues, et ce sera ma faute, pas la vôtre).
Ces tests ne sont pas destinés à vous blâmer mais à aider dans le processus de développement, il est généralement préférable de trouver un bogue avant de l’intégrer à la phase de pré-production en raison d’un échec de test que de le trouver par surprise en production.
2. Sur les grands projets, généralement sur les grandes entreprises., Si vous êtes sur une très grande entreprise, le chef de projet devrait aimer que tout le code ressemble à la même chose (formatage), donc ils ont probablement une peluche quelque part qui vous indique si vous avez ajouté 4 espaces blancs pour indenter quelque chose qu’ils veulent avec 2 et cela vous blâmera si vous n’avez pas déclaré une méthode avec,
je trouve des tonalités de développeurs juniors essayant de lutter contre cela parce qu’ils aiment un formatage particulier, mais sans ces outils, ces grandes applications logicielles ressembleront à un monstre de frankenstein sur un avenir augmentant la difficulté à lire toutes les parties ou à suivre des chemins de méthode et des remplacements de classe. Pensez – y comme lire un livre où chaque paragraphe a une taille de police différente, une famille de polices, etc.
Où ne pas l’utiliser?
ce point est si facile: ne l’utilisez pas sur le contexte dynamique et sur les langages de non-programmation.
1. Le premier est facile à comprendre., Si vous êtes sur un contexte dynamique, le lint (un vérificateur statique) ne connaîtra jamais le résultat final et vous reprochera des choses qui vont bien, j’ajouterai un exemple sur le point suivant.
2. Cela devrait sembler ridicule, redondant ou vous pouvez me dire « où utilisez-vous une peluche si ce n’est pas sur un langage de programmation? »
Mulder, il y a des linters HTML et CSS là-bas.
Oui.. la messagerie unifiée… Mais, comment?,
Eh bien, ils ne sont pas des linters en vérité, ils ne sont que des vérificateurs de code, la même chose que vous pouvez faire avec le validateur w3c, mais au lieu de copier votre code dans un validateur, ils s’exécutent généralement sur le temps de développement en vous blâmant pour différentes choses basées sur l’opinion de quelqu’un, ce qui est ennuyeux, inexact et ne correspond vraiment pas à les raisons ne s’appliquent pas à tous les projets., C’est pourquoi vous trouverez des tons de commentaires « oubliez CSSLint, c’est opiniâtre et ne correspond pas à votre projet » et beaucoup d’autres similaires sur internet.
Vous pouvez trouver des morceaux de code qui sont appelés Linters pour une raison quelconque, mais au moins ils vous disent « je suis un formateur de code opiniâtre » comme celui-ci .,
HTML lint pourrait être utile parfois car il vous obligera à ajouter un attribut alt aux images et à d’autres pratiques d’accessibilité et bonnes pratiques (la plupart deses vous montrent un avertissement pour cela aussi sans ajouter de lint, ce qui est mieux) mais cela ne vous empêchera pas d’utiliser un <span> »>p> ou autre mauvaise utilisation du HTML.
cela vous ennuiera également si vous écrivez des composants de modèle avec des instructions stupides comme « vous n’avez pas de déclaration doctype, vous n’avez pas html, head, title ni body tag., Et vous pourriez « bien sûr, car ce fichier sera chargé dans un document qui a déjà ces balises » mais HTML lint ne peut pas le savoir; Lints sont des vérificateurs statiques et vous travaillez sur un environnement dynamique, alors continuez et supprimez html lint du tout.
CSSLint est un peu différent, il n’y a aucune chose que vous pouvez lint ici de toute façon, vous pouvez écrire du CSS valide ou invalide mais c’est tout.,
Il y a des bonnes pratiques sur CSS qui sont à des fins d’efficacité et de rapidité (cela profitera également à L’UX), d’autres qui iront à des fins de maintenabilité, d’évolutivité et de lisibilité (généralement basées sur l’expérience de développement), d’autres pour l’accessibilité (basées sur des études UI / UX et des rendus Mais il ne sert à rien de combiner tout cela en un linter et de dire aux développeurs de faire correspondre toutes ces pratiques, tout d’abord parce qu’il y a des contradictions qui ont besoin d’un humain pour prendre la décision d’utiliser l’une ou l’autre.,
un cas d’utilisation où choisir pourrait être traité par le fait que l’ajout de tout le code CSS d’accessibilité augmentera de manière observable la taille, le temps de chargement et les métriques interactives pour la première fois, de sorte que vous choisirez généralement uniquement les règles d’accessibilité qui conviennent le mieux à vos clients tout en conservant de bonnes performances.
pour avoir donné un exemple stupide sur une règle opiniâtre sur le CSSLint, disons que je veux un dégradé linéaire en arrière-plan sur mon bloc principal de page d’accueil. CSSLint lancera un avertissement sur les performances de gradient linéaire.,
à ce stade CSSLint veut que vous supprimiez le gradient linéaire mais quelles sont les alternatives?
L’utilisation d’une image sera des tons de fois moins efficaces pour atteindre la conception cible (et réduira également la qualité visuelle du dégradé, et rendra plus difficile le redimensionnement pour s’adapter à toutes les tailles posibles du bloc).
Alors, que pouvons-nous faire? Ignorez simplement le CSSLint, car il est opiniâtre et cela n’est pris en charge par aucune raison.
Il y a une différence sur l’ajout d’un gradient linéaire par rapport à l’ajout de 42342 gradients linéaires sur la même vue., Soit dit en passant, si vous en avez besoin, ce sera toujours plus efficace que d’utiliser des images.
Vous pouvez également y trouver des déclarations contradictoires telles que:
« N’utilisez pas D’ID pour le style ». La raison en est que ce sera une règle non réutilisable.
Et
« N’utilisez pas de classes adjacentes ». Je ne pouvais pas comprendre correctement la raison sans lire l’explication des règles css lint et la raison en est « bien que techniquement autorisée en CSS, celles-ci ne sont pas gérées correctement par Internet Explorer 6 et versions antérieures ».
j’ai quelque chose à vous dire CSSLint., Personne ne se soucie D’IE 6 et plus tôt, Nous sommes en 2020, 99% des logiciels web prend en charge I. E. 11 autant, qui a été publié sur 2013 en passant et a moins d’un 3% d’utilisation.
d’autre part, où pour L’amour de Dieu, il est exprimé que toutes les règles CSS doivent être réutilisables sur la même vue?
Si vous avez un élément unique sur votre application web, c’est-à-dire que vous n’avez probablement qu’une seule barre de navigation, une seule fenêtre contextuelle de chat le cas échéant, un seul logo de barre de navigation et un seul pied de page pour en nommer certains, pourquoi avez-vous besoin d’ajouter son style global? N’est-ce pas une si mauvaise pratique qui est contraire à toutes les autres langues du monde?,
en plus, disons que vous avez 5 vues sur votre projet. Si vous avez un <nav> il sera probablement affiché sur tous, donc le même style que vous mettez ci-dessous #primary-navigation fonctionne sur 5 vues différentes. N’est-ce pas une façon de ré-utilisabilité?
pour augmenter la bêtise autour que les deux règles ensemble, voir comment il vous permet sur une situation difficile.,
Si vous ne pouvez pas utiliser un id pour le style<nav class="dark-theme">, et que vous ne pouvez pas ajouter de classes adjacentes<nav class="primary-navigation dark-theme">, comment allez-vous réussir à étendre votre style et à le rendre plus maintenable, lisible par l’homme et comment le gérez-vous pour
Vous ne pouvez tout simplement pas.
Ce que nous pourrions faire sémantiquement correct et facile à entretenir?, Donnons un exemple:
Voici une autre déclaration qui me fait rire pendant un moment:
évitez les sélecteurs d’attributs non qualifiés « les sélecteurs d’attributs non qualifiés, tels que , correspondent d’abord à tous les éléments, puis vérifient leurs attributs. Cela signifie que les sélecteurs d’attributs non qualifiés ont les mêmes caractéristiques de performance que le sélecteur universel (*) »
mon chéri, ce n’est pas différent de ce qui se passe lors de l’utilisation du sélecteur de classe, d’id ou de balise.
Les étapes du rendu CSS du navigateur sont:
- construire le DOM., Le DOM est une structure de données arborescente contenant tous les nœuds HTML de la page. Chaque nœud contient les données relatives à cet élément HTML (tels que les attributs, les ID et les classes) si le nœud a des éléments HTML comme enfants, il pointera également vers ces nœuds enfants.
- construire le CSSOM. Lorsque le navigateur rencontre une feuille de style CSS (intégrée ou externe), il doit analyser le texte en quelque chose qu’il peut utiliser pour les mises en page et les peintures de style. La structure de données dans laquelle le navigateur transforme CSS est nommée de manière créative CSSOM.
- générer un arbre de rendu., En bref, l’arborescence de rendu contient toutes les informations nécessaires au navigateur pour créer des pixels sur la page. Le navigateur prend essentiellement le DOM et CSSOM et les écrase ensemble, supprimant tout ce qui n’aura pas d’effet sur la sortie rendue.
- mise en page et peinture.
lors de la phase de mise en page, le navigateur calcule la taille et la position des éléments (rien de rendu encore) puis, à l’étape de peinture, il commence à générer des pixels que nous visualiserons.,
comme vous pouvez le voir, vous pourriez avoir un petit biais de performance lorsque vous imbriquez indistinctement vos sélecteurs, comme body>#main-content>.first-block .products-card p car vous générerez des nœuds enfants inutiles dans le CSSOM qui devront correspondre au DOM et cela prendra un peu plus de temps que d’utiliser simplement un.products-card p, mais comme règles donc disons #main-content .products-card p.
c’est une bonne pratique mais je n’ai jamais vu d’application web dans laquelle des sélecteurs plus spécifiques provoquent un goulot d’étranglement de la vitesse de chargement., Cela est généralement dû au fait d’itérer encore et encore en conservant les tons de code inutilisé que le navigateur ajoutera dans CSSOM et devra comparer avec DOM pour savoir s’il est correct de l’ajouter dans l’arborescence de rendu ou non.
pour cela et d’autres raisons, vous pouvez trouver des articles expliquant chaque mauvais point sur CSSLint comme celui-ci qui expliquent les choses de manière plus approfondie que je ne l’ai fait ici.
résumé
les Linters sont bons pour certaines choses et mauvais pour d’autres.,
ils peuvent également être modifiés pour répondre à certains besoins du projet ou certaines préférences de l’entreprise ou de la personne pour éviter ces règles qui sont opiniâtres et en ajoutant d’autres règles précieuses qui correspondent au projet dans lequel vous êtes.
Il existe de nombreuses raisons d’utiliser des linters sur les langages interprétés (sur les langages compilés, l’e et le compilateur s’en occuperont, mais vous pouvez également ajouter un Lint pour vérifier le formatage du code uniquement ou pour obtenir des avertissements avant la compilation pour éviter d’attendre que le compilateur trouve une erreur ou se termine pour savoir,
Il y a peu de raisons d’ajouter des linters en HTML (seules les fins d’accessibilité peuvent être utiles je pense) et il y a moins de raisons d’ajouter des linters sur CSS (qui peuvent être réduits à un code un vérificateur de formatage).
avez-vous utilisé une peluche? Si oui, dites-nous dans quelle langue et quel contexte et quelle a été votre expérience.
personnellement, j’ai aimé après quelques ajustements lors de l’utilisation de la Machine.
Comme toujours, j’espère que vous aimez ce post et meilleures salutations,
Joel