|
|
|
Connus par les développeurs sous le nom ['antipattern ou anti-patron'](https://fr.wikipedia.org/wiki/Antipattern), certaines mauvaises habitudes sont à éviter si on veut que l'ensemble de la communauté puisse, à un moment ou à un autre se saisir de votre code, le comprendre, l'exploiter et si l'on souhaite la survie du projet à long terme.
|
|
|
|
|
|
|
|
Ces antipatterns ont comme effets principaux :
|
|
|
|
|
|
|
|
- une perte de temps (qui peut être exponentielle une fois que le projet grandit).
|
|
|
|
- un code mal structuré qui le rend uniquement compréhensible par son auteur (et encore, il m'arrive de ne plus comprendre ce que j'ai codé il y a 2 ans !).
|
|
|
|
- un code qui n'est plus maintenable sauf à grand frais d'heures de relecture.
|
|
|
|
- des vulnérabilités (des plantages difficilement prévisibles ou corrigibles).
|
|
|
|
|
|
|
|
Dans la suite, je vous proposerai des extraits d'une vidéo où l'auteur explique comment ruiner un projet avec les antipatterns (c'est à prendre avec humour)
|
|
|
|
|
|
|
|
Quels sont les antipatterns les plus répandus ?
|
|
|
|
|
|
|
|
- **L'absence de commentaires.**
|
|
|
|
|
|
|
|
> Parfois le code est suffisamment explicite pour qu'on puisse se passer de commentaires, mais dès lors qu'on atteint une certaine complexité, une certaine longueur, il est bon d'expliquer le pourquoi de ce long code, sans tomber dans l'excès bien sûr car l'excès de commentaire est un antipattern aussi, [voir cet extrait](https://www.youtube.com/watch?v=RG2UG-J26V4#t=6m35s).
|
|
|
|
|
|
|
|
- **Le mauvais nommage des variables.**
|
|
|
|
|
|
|
|
> Donner des noms qui ne signifient rien à vos variables, c'est être certain que dans 1 an, quand vous relirez votre code, vous ne comprendrez plus ce que ça fait, et vous pouvez être certain que personne ne rentrera dans votre code. [Voir cet extrait](https://www.youtube.com/watch?v=RG2UG-J26V4#t=9m54s).
|
|
|
|
|
|
|
|
- **L'utilisation de 'magic number' ou de 'magic string'.**
|
|
|
|
|
|
|
|
> [Voir cet extrait où il explique ce que sont ces constantes qui tombent d'on ne sait où](https://www.youtube.com/watch?v=RG2UG-J26V4#t=13m11s)
|
|
|
|
|
|
|
|
- **Le copier-coller de code.**
|
|
|
|
|
|
|
|
> Ou comment passer pour un pro en développant des kilomètres de code à moindre frais ? L'ennui, c'est que s'il y a un bug dans la séquence que vous avez copiée 10 fois, il faudra le corriger à 10 endroits ! (Je ne balancerai pas, mais ça m'est arrivé de faire ce genre de corrections sur des exos de lycée... )
|
|
|
|
|
|
|
|
**_Voyons maintenant les bonnes pratiques en lien avec les antipatterns cités ci-dessus :_**
|
|
|
|
|
|
|
|
- **Les commentaires :**
|
|
|
|
|
|
|
|
> Il y en a deux sortes :
|
|
|
|
>
|
|
|
|
> 1. les commentaires de bloc (JsDoc) : taper /\*\* au-dessus de la déclaration de la fonction, et un bloc de commentaire JsDoc pré-rempli va apparaître. Ajouter le 'pourquoi de votre fonction', c'est-à-dire une description brève de ce à quoi elle sert. Ne pas paraphraser le code : on ne duplique pas le code dans le commentaire. Et agrémentez chaque @param du type de variable et d'une petite description de ce à quoi elle sert (le fichier 2d.js est bourré de ces commentaires JsDoc).
|
|
|
|
> 2. Les commentaires 'inline' : taper // à la suite d'une ligne de code ou avant une séquence de code si vous pensez qu'il est pertinent de détailler le pourquoi de cette séquence (si le code ne s'explique pas de lui-même).
|
|
|
|
|
|
|
|
- **Les variables :**
|
|
|
|
|
|
|
|
> Bien choisir le nom de ses variables (ou des constantes) est un incontournable pour la relecture du code (on utilisera la convention [camelCase](https://medium.com/@anthowelc/c-est-quoi-le-camelcase-7fa02dc7fcee) dans tout le projet).\
|
|
|
|
> Cela permet le plus souvent de comprendre le pourquoi du code sans avoir besoin de le commenter.\
|
|
|
|
> Cela permet aussi de communiquer sur son code et d'éviter l'effet silo qui consiste à ce que personne d'autre que vous ne peut comprendre votre code.\
|
|
|
|
> Dans l'exemple suivant, pas besoin de commentaire :\
|
|
|
|
> `if (sexe === fille) { taille = tailleFille } else { taille = tailleGarcon }`\
|
|
|
|
> Utiliser une constante quand une variable est affectée à une valeur et ne change pas dans la suite du code.\
|
|
|
|
> Ne déclarer les variables que dans la zone (la plus restreinte possible) où elles sont utilisées ([voir portée des variables en javascript](https://grafikart.fr/tutoriels/portee-variable-2057))\
|
|
|
|
> Les déclarer au plus près de leur utilisation (éviter la déclaration de nombreuses variables utilisées dans un bloc de boucle comme on le voit souvent :\
|
|
|
|
> à proscrire : `for (let i=0, texte, texteCorr, prenom, objet, age, taille, masse; i<this.nbQuestions; i++){ ... }`\
|
|
|
|
> mais préférer déclarer vos variables à l'intérieur du bloc, au plus près de leur usage.\
|
|
|
|
> Si à chaque répétition de la boucle, 'age' prend une valeur et n'en change pas avant la prochaine répétition, alors vous pouvez utiliser : `const age = randint(10,15)` dans le corps de la boucle, au plus près de son usage.
|
|
|
|
|
|
|
|
- **Les magic-numbers, les magic-strings :**
|
|
|
|
|
|
|
|
> Souvent, on trouve tout à fait normal le code suivant : `if (age<18) {...} else {...}`, pourtant ce 18 peut se retrouver un peu partout dans votre code (c'est un magic-number).\
|
|
|
|
> Ce code est plus pertinent :\
|
|
|
|
> `const majorite=18 if (age<majorite) {...} else {...}`\
|
|
|
|
> D'une part, cela rend le code plus lisible (on explique le 'pourquoi'), d'autre part, si un jour on décide de changer cette 'majorité', il suffira de changer une seule ligne de code, et non pas les 36 usages du nombre 18 présent dans le code.\
|
|
|
|
> Pire encore pour la compréhension est l'usage de magic-number comme index de tableau :\
|
|
|
|
> `if (objet[3]===15) { ... }` ne permet absolument pas de connaître le pourquoi !\
|
|
|
|
> On ne sait pas ce que représente l'élément d'index 3 de la liste objet.\
|
|
|
|
> Par contre :\
|
|
|
|
> `const duration = 3 if (objet[duration]===durationLimite) {...}` : là, ça prend tout son sens !\
|
|
|
|
> La raison de ne pas utiliser de magic-string est moins évidente...\
|
|
|
|
> Je reprends un exemple précédent :\
|
|
|
|
> `if (sexe==='fille') {taille = tailleFille} else {taille = tailleGarcon}`.\
|
|
|
|
> Ici, on peut se dire que c'est du code bien fait...\
|
|
|
|
> Mais si ce 'fille' se retrouve 25 fois dans votre code, et qu'on vous demande un jour une traduction en anglais, sexe étant obtenu par la lecture d'un formulaire...\
|
|
|
|
> Vous commencez à voir ?\
|
|
|
|
> `const fille = 'fille'` peut être aisément remplacé par `const fille = 'girl'` !\
|
|
|
|
> Et une seule valeur modifiée se répercute partout dans le projet ou le bloc concerné suivant la portée de la constante.
|
|
|
|
|
|
|
|
Pour aller plus loin si vous le souhaitez, je vous suggère cette formation en ligne avec [Grafikart](https://grafikart.fr/formations/formation-javascript) |
|
|
\ No newline at end of file |
