Dites adieu aux mauvaises pratiques javascript

Nov 29 2022

Lorsque nous faisons nos premiers pas dans le monde merveilleux de la programmation, nous voyons par nous-mêmes ce qu'elle fait pour des millions de personnes. C'est grâce à la programmation que la vie de tant de personnes est simplifiée, simplement en appuyant sur quelques touches de leurs appareils (c'est magique).

La programmation est un autre type de superpuissance, mais comme l'oncle Ben l'a dit à son neveu, Peter Parker, "Avec un grand pouvoir vient une grande responsabilité." Dans le monde de la programmation, notre plus grande responsabilité est de nous assurer que le code que nous écrivons est à la fois facilement testable et restera maintenable dans le temps.

Certaines petites pratiques de programmation peuvent avoir un impact négatif continu sur le code que nous écrivons et sur le produit que nous créons en tant que résultat final. J'ai vécu ces problèmes de première main. Il est important de partager ce qu'ils sont et pourquoi vous devriez les éviter à tout prix.

1. Utiliser var au lieu de let et const

Il est temps de dire au revoir à l'utilisation de var.

Vous ne devez utiliser que let et const pour ces raisons :

● La portée est plus claire (entre accolades).

● Il ne crée pas d'objets globaux.

● Il signale les erreurs si vous les déclarez à nouveau.

À moins que vous n'utilisiez un navigateur plus ancien tel que le bien-aimé IE11, il est dans votre intérêt de laisser tomber var. Let et const seront vos meilleurs amis à l'avenir.

2. Utiliser des commentaires pour expliquer le code

Les commentaires sont un élément fondamental lorsque nous construisons un logiciel, ils nous aident à comprendre un peu mieux le code que nous lisons, mais il ne faut pas tomber dans l'erreur d'expliquer pas à pas ce que fait notre code, il faut créer du code facile à lire. lire et les commentaires ne doivent fournir que le contexte.

Voici quelques conseils et rappels pour vous aider à rédiger des commentaires de code comme un pro :

● Evitez la redondance dans vos commentaires ; n'écris pas ce que tu fais, écris pourquoi tu le fais.

● Les noms descriptifs des variables/fonctions/classes sont préférables aux commentaires descriptifs.

● Résumez autant que possible ; n'écrivez pas de paragraphes si ce n'est pas absolument nécessaire.

● Essayez de toujours utiliser le même langage et le même style de commentaires.

● Au fil du temps, les commentaires ne sont généralement pas maintenus (modifiés), le code l'est.

3. Utiliser == au lieu de ===

La première chose à comprendre est que bien qu'ils soient visuellement très similaires, ils font des choses différentes : le premier est appelé opérateur d'égalité régulier (==) et le second est appelé opérateur d'égalité stricte (===).

L'opérateur d'égalité régulier (==) vérifie uniquement si les opérandes sont similaires, ce qui peut entraîner des surprises désagréables.

L'opérateur d'égalité stricte (===) vérifie toujours que les opérandes sont de types et de valeurs différents et qu'ils sont exactement les mêmes.

4. Oublier d'utiliser le chaînage optionnel

L'opérateur de chaînage facultatif (?) vous permet de lire la valeur d'une propriété située au plus profond d'une chaîne d'objets connectés sans avoir à vérifier chaque référence de la chaîne.

Cela nous aide à éviter les erreurs lorsque vous essayez d'accéder à une propriété inexistante. Par exemple, disons que nous avons un objet Pokémon qui contient les informations de ce Pokémon.

Lorsque nous voulons accéder à une propriété qui n'est pas définie, comme dans cet exemple, l'accès à la propriété 'attack' Javascript générera une erreur et notre application se cassera. Lors de l'utilisation d'un chaînage optionnel (?), Javascript nous dira que la propriété est indéfinie mais ne générera aucune erreur. Penser à ces types d'erreurs qui sont parfois hors de notre contrôle fait une grande différence à long terme.

5. Ne pas utiliser de chaînes magiques et de nombres magiques

Un nombre magique ou des chaînes magiques sont des nombres ou des chaînes utilisés directement dans le code qui n'ont souvent pas de contexte clair mais qui ont un but. Il est préférable d'affecter ces valeurs à des constantes, car elles peuvent devenir difficiles à comprendre et à déboguer autrement.

6. Mauvaise gestion des erreurs d'appel d'API

Nous devrions toujours gérer les erreurs avec un try/catch dans notre async/wait.

Si nous ne gérons pas les erreurs dans nos promesses, il est très probable que notre application explose, et croyez-moi, nous ne voulons pas que cela se produise.

7. Utiliser un objet comme paramètre unique

Lors de la déclaration d'une fonction où plusieurs valeurs sont attendues d'un objet, il est préférable d'utiliser plusieurs paramètres d'entrée au lieu d'entrées d'objet unique. Cela nous aide pour plusieurs choses :

Tout d'abord, cela facilite la lecture de notre code en sachant dès le début de quels paramètres notre fonction a besoin.

Deuxièmement, cela rend la fonction plus facile à tester, et ces deux choses ensemble aident notre produit à être maintenable dans le temps. De plus, en plus, cela améliore les performances de notre application en évitant de collecter des ordures ou de créer des paramètres d'objet inutiles.

Un autre plus est que si vous utilisez TypeScript et que vous avez plusieurs paramètres, il est plus facile de définir l'interface des paramètres pour bénéficier de la vérification de type et des auto-suggestions ce qui nous évite les erreurs.

8. Oublier le pouvoir des abréviations

Nous avons tous été dans la position de nous demander si une variable existe ou si elle contient une sorte de valeur autre que nulle ou indéfinie. De ce fait, on finit souvent par faire des validations super longues de ce type :

Les abréviations nous aident à éviter ce problème. De manière plus simple et plus élégante, le code ci-dessus peut être réduit à ce qui suit :

Conclusion

Écrire du code propre sera toujours notre responsabilité. Dans mon expérience en tant que développeur, j'ai appris qu'avoir un code maintenable et facile à lire vous fera gagner, à vous et à votre équipe, de nombreuses heures.

Rappelez-vous que nous passons plus de temps à lire du code qu'à l'écrire. J'espère que ces petits conseils vous faciliteront la tâche de créer des produits magiques et étonnants.