Notre code doit être aussi clair et facile à lire que possible.
C’est en fait l’art de la programmation : prendre une tâche complexe et la coder d’une manière à la fois correcte et lisible par l’homme. Un bon style de code y contribue grandement.
Voici un aide-mémoire avec quelques règles suggérées (voir ci-dessous pour plus de détails) :
Discutons maintenant en détail des règles et de leurs raisons.
Il n’y a pas de règles « vous devez »
Rien n’est gravé ici. Ce sont des préférences de style et non des dogmes religieux.
Dans la plupart des projets JavaScript, les accolades sont écrites dans le style « égyptien », avec l'accolade ouvrante sur la même ligne que le mot-clé correspondant – et non sur une nouvelle ligne. Il devrait également y avoir un espace avant le support d'ouverture, comme ceci :
si (condition) {
// fais ça
// ...et ça
// ...et ça
} Une construction sur une seule ligne, telle que if (condition) doSomething() , est un cas limite important. Devons-nous utiliser un appareil dentaire ?
Voici les variantes annotées afin que vous puissiez juger par vous-même de leur lisibilité :
? Les débutants font parfois ça. Mauvais! Les accolades ne sont pas nécessaires :
if (n < 0) {alert(`Power ${n} n'est pas pris en charge`);}? Divisé en une ligne distincte sans accolades. Ne faites jamais ça, il est facile de faire une erreur lors de l'ajout de nouvelles lignes :
si (n < 0)
alert(`Power ${n} n'est pas pris en charge`);? Une ligne sans accolades – acceptable, si elle est courte :
if (n < 0) alert(`Power ${n} n'est pas pris en charge`);? La meilleure variante :
si (n < 0) {
alert(`Power ${n} n'est pas pris en charge`);
} 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.
Personne n’aime lire une longue ligne de code horizontale. Il est préférable de les diviser.
Par exemple:
// guillemets inversés ` permettent de diviser la chaîne en plusieurs lignes laissez str = ` Le TC39 d'ECMA International est un groupe de développeurs JavaScript, responsables de la mise en œuvre, universitaires et plus encore, collaborant avec la communauté pour maintenir et faire évoluer la définition de JavaScript. `;
Et, pour les instructions if :
si (
identifiant === 123 &&
moonPhase === 'Gibbou décroissant' &&
Signe du zodiaque === 'Balance'
) {
letTheSorceryBegin();
}La longueur maximale de la ligne doit être convenue au niveau de l'équipe. Il s'agit généralement de 80 ou 120 caractères.
Il existe deux types de retraits :
Retraits horizontaux : 2 ou 4 espaces.
Une indentation horizontale est réalisée à l'aide de 2 ou 4 espaces ou du symbole de tabulation horizontale (touche Tab ). Laquelle choisir est une vieille guerre sainte. Les espaces sont plus courants de nos jours.
L'un des avantages des espaces par rapport aux tabulations est que les espaces permettent des configurations de retraits plus flexibles que le symbole de tabulation.
Par exemple, nous pouvons aligner les paramètres avec le crochet ouvrant, comme ceci :
show(paramètres,
aligné, // 5 espaces de remplissage à gauche
un,
après,
un autre
) {
//...
}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 répartis verticalement :
fonction pow(x, n) {
soit le résultat = 1 ;
// <--
pour (soit i = 0; i < n; i++) {
résultat *= x ;
}
// <--
renvoyer le résultat ;
}Insérez une nouvelle ligne supplémentaire là où cela contribue à rendre le code plus lisible. Il ne doit pas y avoir plus de neuf lignes de code sans indentation verticale.
Un point-virgule doit être présent après chaque instruction, même s'il peut éventuellement être ignoré.
Il existe des langues dans lesquelles le point-virgule est vraiment facultatif et est rarement utilisé. En JavaScript, cependant, il existe des cas où un saut de ligne n'est pas interprété comme un point-virgule, ce qui rend le code vulnérable aux erreurs. Pour en savoir plus, consultez le chapitre Structure du code.
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.
Essayez d'éviter d'imbriquer le code sur trop de niveaux.
Par exemple, dans la boucle, c'est parfois une bonne idée d'utiliser la directive continue pour éviter une imbrication supplémentaire.
Par exemple, au lieu d’ajouter un if conditionnel imbriqué comme ceci :
pour (soit i = 0; i < 10; i++) {
si (suite) {
... // <- un niveau d'imbrication supplémentaire
}
}On peut écrire :
pour (soit i = 0; i < 10; i++) {
if (!cond) continue ;
... // <- pas de niveau d'imbrication supplémentaire
} Une chose similaire peut être faite avec if/else et return .
Par exemple, deux constructions ci-dessous sont identiques.
Option 1 :
fonction pow(x, n) {
si (n < 0) {
alert("Négatif 'n' non pris en charge");
} autre {
soit le résultat = 1 ;
pour (soit i = 0; i < n; i++) {
résultat *= x ;
}
renvoyer le résultat ;
}
}Option 2 :
fonction pow(x, n) {
si (n < 0) {
alert("Négatif 'n' non pris en charge");
retour;
}
soit le résultat = 1 ;
pour (soit i = 0; i < n; i++) {
résultat *= x ;
}
renvoyer le résultat ;
} Le second est plus lisible car le « cas particulier » de n < 0 est traité très tôt. Une fois la vérification effectuée, nous pouvons passer au flux de code « principal » sans avoir besoin d'une imbrication supplémentaire.
Si vous écrivez plusieurs fonctions « d’assistance » et le code qui les utilise, il existe trois manières d’organiser les fonctions.
Déclarez les fonctions au-dessus du code qui les utilise :
// déclarations de fonctions
fonction createElement() {
...
}
fonction setHandler(elem) {
...
}
fonction walkAround() {
...
}
// le code qui les utilise
laissez elem = createElement();
setHandler(elem);
walkAround();Coder d’abord, puis fonctionner
// le code qui utilise les fonctions
laissez elem = createElement();
setHandler(elem);
walkAround();
// --- fonctions d'assistance ---
fonction createElement() {
...
}
fonction setHandler(elem) {
...
}
fonction walkAround() {
...
}Mixte : une fonction est déclarée là où elle est utilisée pour la première fois.
La plupart du temps, la deuxième variante est privilégiée.
En effet, lorsque nous lisons du code, nous voulons d'abord savoir ce qu'il fait . Si le code apparaît en premier, il devient clair dès le début. Ensuite, nous n'aurons peut-être pas du tout besoin de lire les fonctions, surtout si leurs noms décrivent ce qu'elles font réellement.
Un guide de style contient des règles générales sur « comment écrire » du code, par exemple quelles guillemets utiliser, combien d'espaces mettre en retrait, la longueur maximale de ligne, 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 rédiger son propre guide de style, mais ce n’est généralement pas nécessaire. Il existe de nombreux guides parmi lesquels choisir.
Quelques choix populaires :
Guide de style Google JavaScript
Guide de style JavaScript d'Airbnb
Idiomatique.JS
StandardJS
(et bien d'autres)
Si vous êtes un développeur novice, commencez par l'aide-mémoire 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.
Les linters sont des outils qui peuvent vérifier automatiquement le style de votre code et faire des suggestions d'amélioration.
L'avantage d'eux est que la vérification du style peut également détecter des bugs, comme des 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 peluchage bien connus :
JSLint – l'un des premiers linters.
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 : activez simplement le plugin dans l'éditeur et configurez le style.
Par exemple, pour ESLint, vous devez procéder comme suit :
Installez Node.js.
Installez ESLint avec la commande npm install -g eslint (npm est un programme d'installation de package JavaScript).
Créez un fichier de configuration nommé .eslintrc à la racine de votre projet JavaScript (dans le dossier qui contient tous vos fichiers).
Installez/activez le plugin pour votre éditeur qui s'intègre à ESLint. La majorité des éditeurs en possèdent un.
Voici un exemple de fichier .eslintrc :
{
"extends": "eslint: recommandé",
"env": {
"navigateur" : vrai,
"noeud": vrai,
"es6" : vrai
},
"règles": {
"pas de console": 0,
"retrait": 2
}
} Ici, la directive "extends" indique que la configuration est basée sur l'ensemble de paramètres « eslint:recommended ». Après cela, nous précisons le nôtre.
Il est également possible de télécharger des ensembles de règles de style à partir du Web et de les étendre à la place. Voir https://eslint.org/docs/user-guide/getting-started pour plus de détails sur l'installation.
Certains IDE ont également un peluchage intégré, ce qui est pratique mais pas aussi personnalisable qu'ESLint.
Toutes les règles de syntaxe décrites dans ce chapitre (et dans les guides de style référencés) visent à augmenter la lisibilité de votre code. Tous sont discutables.
Lorsque nous pensons à écrire un « meilleur » code, les questions que nous devrions nous poser sont les suivantes : « Qu’est-ce qui rend le code plus lisible et plus facile à comprendre ? et "Qu'est-ce qui peut nous aider à éviter les erreurs ?" Ce sont les principales choses à garder à l’esprit lors du choix et du débat sur les styles de code.
La lecture de guides de style populaires vous permettra de vous tenir au courant des dernières idées sur les tendances et les meilleures pratiques en matière de style de code.
importance : 4
Quel est le problème avec le style de code ci-dessous ?
fonction pow(x,n)
{
soit résultat = 1 ;
pour (soit i=0;i<n;i++) {result*=x;}
renvoyer le résultat ;
}
soit x=prompt("x?",''), n=prompt("n?",'')
si (n<=0)
{
alert(`Power ${n} n'est pas pris en charge, veuillez entrer un nombre entier supérieur à zéro`);
}
autre
{
alerte(pow(x,n))
}Réparez-le.
Vous pourriez noter ce qui suit :
fonction pow(x,n) // <- pas d'espace entre les arguments
{ // <- figure parenthèse sur une ligne séparée
soit résultat = 1 ; // <- pas d'espace avant ou après =
for(let i=0;i<n;i++) {result*=x;} // <- pas d'espaces
// le contenu de { ... } doit être sur une nouvelle ligne
renvoyer le résultat ;
}
let x=prompt("x?",''), n=prompt("n?",'') // <-- techniquement possible,
// mais il vaut mieux faire 2 lignes, il n'y a pas non plus d'espaces et il manque ;
if (n<=0) // <- pas d'espace à l'intérieur de (n <= 0), et devrait être une ligne supplémentaire au-dessus
{ // <- figure parenthèse sur une ligne séparée
// ci-dessous - les longues lignes peuvent être divisées en plusieurs lignes pour une meilleure lisibilité
alert(`Power ${n} n'est pas pris en charge, veuillez entrer un nombre entier supérieur à zéro`);
}
else // <- pourrait l'écrire sur une seule ligne comme "} else {"
{
alert(pow(x,n)) // pas d'espace et manquant ;
}La variante fixe :
fonction pow(x, n) {
soit le résultat = 1 ;
pour (soit i = 0; i < n; i++) {
résultat *= x ;
}
renvoyer le résultat ;
}
let x = prompt("x?", "");
let n = prompt("n?", "");
si (n <= 0) {
alert(`Power ${n} n'est pas pris en charge,
veuillez entrer un nombre entier supérieur à zéro`);
} autre {
alerte( pow(x, n) );
}