Respirer de l'air dans le guide de style JavaScript d'AirBnB

Personne ne se propose d'écrire du code laid et de style incohérent. Cela arrive en quelque sorte.

Même en tant que seul développeur sur un projet, plus le temps passe et plus vous produisez de code, plus il est difficile de maintenir un style de code cohérent.

C'est pourquoi vous avez besoin d'un guide de style.

J'ai constaté de première main tout ce que les équipes peuvent accomplir après avoir adopté un guide de style.

Vous n'avez plus besoin de faire de petits appels de jugement de style tout au long de la journée. Consultez simplement le guide de style.

Et lorsqu'un coéquipier a besoin de maintenir votre code, c'est du code propre qu'il peut lire et comprendre.

L'adoption d'un guide de style est l'une des choses les plus simples que vous puissiez faire pour améliorer la maintenabilité de votre code, ce qui augmente finalement la productivité de votre équipe. Explorons donc la manière la plus populaire de le faire.

Entrez AirBnB + ESLint

L'écosystème JavaScript offre une grande variété d'outils et de guides de style. Ceci ne devrait étonner personne. avec JavaScript, nous nous attendons à une grande variété de tout.

Mais à mesure que l'écosystème mûrit, les développeurs expérimentés commencent à aspirer à «la manière standard» de faire les choses qu'offrent des écosystèmes plus solidifiés.

Vous êtes bien sûr le bienvenu pour passer quelques jours à explorer l'écosystème JavaScript et à comparer différents outils, mais je vais essayer de vous faire gagner du temps : ESLint est l'outil de linting JavaScript le plus populaire, et le guide de style d'AirBnB est le plus utilisé. guide de style.

Pour plus de détails sur l'ajout d'ESLint à votre projet, consultez ce lien.

Une fois que vous avez tout compris, vous pouvez configurer votre projet pour appliquer le guide de style d'AirBnB en installant leur package npm:

npm install --save-dev eslint-config-airbnb

Ajoutez la ligne suivante dans votre fichier .eslintrc

"extends": "airbnb"

Et voilà! Votre code est désormais soumis aux règles du guide de style JavaScript le plus populaire. Bon codage!

Les normes sont surestimées

Bien que je sois d'accord avec la plupart des règles du guide de style, voici une liste de remplacements que j'ai compilés. Voici à quoi ressemblent les fichiers .eslintrc dans les dossiers racine des projets:

Laissez-moi vous expliquer en détail le raisonnement derrière chacune de ces personnalisations.

Échancrure

Les onglets VS Space War peuvent potentiellement ruiner les amitiés et même saboter les relations amoureuses.

Je préfère mettre en retrait mon code de 4 espaces, même si la grande majorité des configurations préfèrent une indentation de 2.

Mon raisonnement est que pour écrire du code propre, des indentations plus grandes vous donnent une meilleure représentation visuelle de la profondeur de l'imbrication dans vos fonctions et du nombre de branches différentes que vous avez.

Vous ne devriez certainement pas imbriquer du code à plus de 3 ou 4 couches dans un fichier JavaScript (c'est une odeur de code). Ainsi, avoir 4 espaces vous offre une meilleure lisibilité, tout en préservant d'autres règles comme garder votre code dans une limite de 80 ou 120 caractères par ligne.

En outre, l'indentation est l'une des règles qui insuffle plus «d'air» dans le guide de style par défaut d'AirBnB. En conséquence, votre code ne se presse pas trop du côté gauche de l'éditeur.

Espacement

C'est probablement le plus grand écart par rapport à la norme. Je déteste le code encombré. J'ai commencé à écrire du code avec un espace supplémentaire il y a plus de 2 ans, et je n'ai jamais regardé en arrière.

Alors, que signifient ces règles? Eh bien, regardez le code suivant. Il respecte techniquement les règles du guide de style officiel d'AirBnB.

Je sais, c'est un peu déroutant. J'ai essayé de rechercher une fonction de complexité moyenne dans l'une de mes bases de code, mais j'ai dû en masquer beaucoup, alors n'essayez pas de comprendre la logique derrière le code (car il n'y en a pas). Essayez simplement de le lire. Essayez de vous concentrer, par exemple, sur les variables qui sont utilisées à plusieurs endroits, lorsque les paramètres sont passés aux fonctions et où se trouvent les appels de fonction.

Maintenant, regardez le même code, mais avec les règles d'espacement supplémentaires appliquées:

Je ne dis pas que c'est très lisible maintenant, mais vous pouvez plus facilement identifier où vous avez des paramètres envoyés aux fonctions - en particulier autour des fonctions curry.

Vérifiez également la différence entre l'indentation à 2 et 4 espaces dans les deux exemples.

Au début, ces techniques peuvent ne pas sembler être une grande amélioration. Je vous encourage à les essayer. Je pense que vous découvrirez rapidement à quel point cela fait une différence.

Guerres de citation

Bien que les deux premières catégories aient des arguments clairs, je dois dire que la décision entre guillemets simples ou doubles est très subjective.

Ma préférence pour les guillemets doubles vient probablement de travailler beaucoup avec React, où vous mélangez JavaScript avec des balises JSX. Puisque JSX est plus proche du HTML, la tendance est d'ajouter des attributs entre guillemets. J'ai donc commencé à utiliser des guillemets doubles pour tout, juste pour la cohérence.

Une chose que j'ai remarquée, c'est que vous êtes beaucoup plus susceptible d'avoir besoin d'écrire un guillemet simple dans une chaîne de texte anglais qu'un guillemet double («Je suis ici», «Ne faites pas ça»). Les guillemets doubles peuvent donc être plus pratiques dans ces cas.

Disposition des codes

Le guide de style officiel d'AirBnB a une règle «pas d'utilisation avant de définir», qui génère une erreur si vous essayez d'utiliser quelque chose avant de le définir. C'est une bonne règle - en particulier pour les variables - car vous ne devez pas vous fier au levage, et vous devez garder à l'esprit le problème de la zone morte temporelle lorsque vous utilisez let et const.

Je préfère autoriser l'utilisation des fonctions avant qu'elles ne soient définies. La raison est simple: la plupart du temps, vous décomposerez vos fonctions en sous-fonctions plus petites. Cependant, la règle «no-use-before-define» vous dira de placer ces sous-fonctions avant la fonction d'origine.

Mais vos sous-fonctions sont là pour faire abstraction de parties de l'algorithme. Ils ne devraient pas vous déranger lorsque vous ouvrez un fichier contenant votre fonction de niveau supérieur , que vous utilisez en dehors du fichier.

Bien sûr, cela est discutable. Mais cela a un impact sur le débogage. Lorsque vous parcourez du code et que vous trouvez un appel à une fonction différente, idéalement, vous devriez pouvoir regarder en dessous, ou - dans le pire des cas - faire défiler quelques sous-fonctions et trouver ce que vous recherchez.

Ceci, en combinaison avec la déclaration de fonction d'AirBnB contre l' expression de fonctionrègle,peut vous donner la liberté de structurer vos modules ou bibliothèques de fonctions comme vous le souhaitez, tout en vous assurant de ne pas appeler accidentellement une fonction non initialisée.

Const sur laisser

Voici un autre petit écart par rapport au guide de style. Vous pouvez remarquer dans ma config:

"prefer-const": 1

Dans la configuration AirBnB, il est défini sur 2, ce qui signifie erreur , tandis que 1 signifie avertissement .

Maintenant, si vous ne comprenez pas pourquoi vous devriez préférer const à let, vous pouvez en savoir plus ici et ici.

Concernant mon écart, je préfère un avertissement, car il existe des situations dans lesquelles vous ne modifiez pas l'affectation d'une variable, mais vous modifiez une grande partie de son contenu.

Jetez un œil à ce code:

Les règles vous diront que c'est correct - le hachage doit être constant car il n'est pas réaffecté. Mais cela n'a jamais vraiment eu de sens pour moi. Je devrais être conscient qu'il y a beaucoup de changements dans le hash.

J'utiliserai donc let pour signaler que la variable est sujette à changement. const et let devraient donner plus de sens à vos variables et ne devraient en aucun cas cacher la vérité.

Complexité du code

Vous pouvez la complexité du code cyclomatique pour calculer la complexité de chacune de vos fonctions.

Décider d'un niveau maximal de complexité est délicat. Idéalement, il devrait être aussi bas que possible, ce qui signifie que vos fonctions devraient avoir au plus 1 ou 2 possibilités de branchement.

Il est logique d'avoir ce nombre aussi bas que possible du point de vue de la réutilisation et des tests du code. Mais il y a des moments où il est plus difficile de décomposer des fonctions. C'est pourquoi je vois la complexité plus comme un avertissement que comme une erreur.

L'important ici est de limiter le nombre de fonctions qui atteignent cette limite de complexité maximale. Même dans une base de code de taille moyenne, je n'aimerais pas voir plus de 10 fonctions qui enfreignent cette règle. J'ai donc choisi la valeur maximale de 5, afin de mettre en évidence ces fonctions. Je ciblerai ces fonctions lorsque j'aurai le temps de refactoriser.

La complexité peut être résolue de plusieurs manières. La refactorisation en fonctions plus petites est la plus évidente. Une autre option consiste à transformer vos instructions de commutation en affectations de mappage.

Nous avons eu plusieurs débats au sein de notre équipe, et nous avons fini par utiliser 5 comme valeur de référence pour la règle de complexité maximale. Mais dans certains cas, nous descendons à 4, juste pour être sûrs que nous écrivons du code propre et simple.

Une note sur React

Parce que je travaille beaucoup avec React et que la configuration AirBnB contient également un grand nombre de règles dans ce domaine, je voulais également inclure certaines de mes préférences à ce sujet.

L'objectif principal de mes remplacements React est de limiter la différenciation entre les modules JavaScript normaux et les composants React, ainsi qu'entre le code JavaScript et JSX. C'est pourquoi je choisis une indentation similaire et l'utilisation de guillemets doubles pour tous les attributs JSX. Et c'est pourquoi je préfère laisser tous mes fichiers avec l'extension .js.

Enfin, en ce qui concerne les composants classe vs usine, j'ai tendance à préférer ce dernier. Je ne vois aucun avantage à utiliser des classes à ce stade. Je pourrais écrire un futur article expliquant pourquoi je ressens cela.

C'est à peu près ça! J'espère que vous avez aimé lire ceci. J'apprécie vos commentaires ci-dessous.

Si vous avez aimé l'article, cliquez sur le cœur vert ci-dessous, et je saurai que mes efforts ne sont pas vains.