Notre code doit être aussi propre et facile à lire que possible.

C’est en fait l’art de la programmation – de prendre une tâche complexe et de la coder d’une manière à la fois correcte et lisible par l’homme. Un bon style de code aide grandement à cela.

Syntaxe

Voici une feuille de triche avec quelques règles suggérées (voir ci-dessous pour plus de détails):

Discutons maintenant des règles et des raisons en détail.

Accolades

Dans la plupart des projets JavaScript, les accolades sont écrites en style « égyptien » avec l’accolade d’ouverture sur la même ligne que le mot–clé correspondant – pas sur une nouvelle ligne. Il devrait également y avoir un espace avant le support d’ouverture, comme ceci:

if (condition) { // do this // ...and that // ...and that}

Une construction à une seule ligne, telle que if (condition) doSomething(), est un cas de bord important. Devrions-nous utiliser des accolades?

Voici les variantes annotées afin que vous puissiez juger de leur lisibilité par vous-même :

Pour un code très bref, une ligne est autorisée, par exemple if (cond) return null. Mais un bloc de code (la dernière variante) est généralement plus lisible.

Longueur de ligne

Personne n’aime lire une longue ligne horizontale de code. C’est la meilleure pratique de les diviser.

Par exemple :

// backtick quotes ` allow to split the string into multiple lineslet str = ` ECMA International's TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript.`;

Et, pour les instructions if:

if ( id === 123 && moonPhase === 'Waning Gibbous' && zodiacSign === 'Libra') { letTheSorceryBegin();}

La longueur maximale de la ligne doit être convenue au niveau de l’équipe. C’est généralement 80 ou 120 caractères.

Indentations

Il existe deux types d’indentations :

• Indentations horizontales : 2 ou 4 espaces.

  Une indentation horizontale est faite en utilisant 2 ou 4 espaces ou le symbole de tabulation horizontale (tabulation de touche). Lequel choisir est une vieille guerre sainte. Les espaces sont plus courants de nos jours.

  Un avantage des espaces par rapport aux onglets est que les espaces permettent des configurations de retrait plus flexibles que le symbole de tabulation.

  Par exemple, nous pouvons aligner les paramètres avec le support d’ouverture, comme ceci:

  show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ...}

• Retraits verticaux: lignes vides pour diviser le code en blocs logiques.

  Même une seule fonction peut souvent être divisée en blocs logiques. Dans l’exemple ci-dessous, l’initialisation des variables, la boucle principale et le retour du résultat sont divisés verticalement:

  function pow(x, n) { let result = 1; // <-- for (let i = 0; i < n; i++) { result *= x; } // <-- return result;}

  Insérez une nouvelle ligne supplémentaire où cela aide à rendre le code plus lisible. Il ne devrait pas y avoir plus de neuf lignes de code sans indentation verticale.

Points-virgules

Un point-virgule doit être présent après chaque instruction, même s’il peut éventuellement être ignoré.

Il existe des langages où un point-virgule est vraiment facultatif et il est rarement utilisé. En JavaScript, cependant, il existe des cas où un saut de ligne n’est pas interprété comme un point-virgule, laissant le code vulnérable aux erreurs. En savoir plus à ce sujet dans la structure du code du chapitre.

Si vous êtes un programmeur JavaScript expérimenté, vous pouvez choisir un style de code sans point-virgule comme StandardJS. Sinon, il est préférable d’utiliser des points-virgules pour éviter d’éventuels pièges. La majorité des développeurs mettent des points-virgules.

Niveaux d’imbrication

Essayez d’éviter d’imbricer le code trop de niveaux en profondeur.

Par exemple, dans la boucle, il est parfois judicieux d’utiliser la directive continue pour éviter l’imbrication supplémentaire.

Par exemple, au lieu d’ajouter un ifconditionnel imbriqué comme ceci :

for (let i = 0; i < 10; i++) { if (cond) { ... // <- one more nesting level }}

Nous pouvons écrire:

for (let i = 0; i < 10; i++) { if (!cond) continue; ... // <- no extra nesting level}

Une chose similaire peut être faite avec if/else et return.

Par exemple, deux constructions ci-dessous sont identiques.

Option 1:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); } else { let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result; }}

Option 2:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); return; } let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result;}

Le le second est plus lisible car le « cas particulier” de n < 0 est géré tôt. Une fois la vérification effectuée, nous pouvons passer au flux de code « principal” sans avoir besoin d’imbrication supplémentaire.

Placement des fonctions

Si vous écrivez plusieurs fonctions « auxiliaires » et le code qui les utilise, il existe trois façons d’organiser les fonctions.

La plupart du temps, la deuxième variante est préférée.

C’est parce que lors de la lecture du code, nous voulons d’abord savoir ce qu’il fait. Si le code passe en premier, il devient clair dès le début. Ensuite, peut-être n’aurons-nous pas du tout besoin de lire les fonctions, surtout si leurs noms sont descriptifs de ce qu’elles font réellement.

Guides de style

Un guide de style contient des règles générales sur « comment écrire » du code, par exemple les guillemets à utiliser, le nombre d’espaces à indenter, la longueur de ligne maximale, etc. Beaucoup de choses mineures.

Lorsque tous les membres d’une équipe utilisent le même guide de style, le code semble uniforme, quel que soit le membre de l’équipe qui l’a écrit.

Bien sûr, une équipe peut toujours écrire son propre guide de style, mais généralement il n’y en a pas besoin. Il existe de nombreux guides existants parmi lesquels choisir.

Quelques choix populaires:Le Guide de style JavaScript de Google (en anglais) est un Guide de Style JavaScript pour Airbnb (en anglais).JS

Si vous êtes un développeur novice, commencez par la feuille de triche au début de ce chapitre. Ensuite, vous pouvez parcourir d’autres guides de style pour trouver plus d’idées et décider laquelle vous préférez.

Linters automatisés

Les linters sont des outils qui peuvent automatiquement vérifier le style de votre code et faire des suggestions d’amélioration.

La grande chose à leur sujet est que la vérification de style peut également trouver des bogues, comme les fautes de frappe dans les noms de variables ou de fonctions. En raison de cette fonctionnalité, l’utilisation d’un linter est recommandée même si vous ne souhaitez pas vous en tenir à un « style de code” particulier.

Voici quelques outils de peluches bien connus:

• JSLint – l’un des premiers peluches.
• JSHint – plus de paramètres que JSLint.
• ESLint – probablement le plus récent.

Tous peuvent faire le travail. L’auteur utilise ESLint.

La plupart des linters sont intégrés à de nombreux éditeurs populaires: il suffit d’activer le plugin dans l’éditeur et de configurer le style.

Par exemple, pour ESLint, vous devez effectuer les opérations suivantes :

1. Install Node.js.
2. Installez ESLint avec la commande npm install -g eslint (npm est un installateur de paquets JavaScript).
3. Créez un fichier de configuration nommé .eslintrc à la racine de votre projet JavaScript (dans le dossier qui contient tous vos fichiers).
4. Installez/activez le plugin pour votre éditeur qui s’intègre à ESLint. La majorité des éditeurs en ont un.

Voici un exemple de fichier .eslintrc:

{ "extends": "eslint:recommended", "env": { "browser": true, "node": true, "es6": true }, "rules": { "no-console": 0, "indent": 2 }}