13 points remarquables du guide de style JavaScript de Google

Pour tous ceux qui ne le connaissent pas déjà, Google publie un guide de style pour l'écriture de JavaScript qui présente (ce que Google pense être) les meilleures pratiques stylistiques pour écrire un code propre et compréhensible.

Ce ne sont pas des règles strictes pour écrire du JavaScript valide, mais uniquement des interdictions pour maintenir des choix de style cohérents et attrayants dans vos fichiers sources. Ceci est particulièrement intéressant pour JavaScript, qui est un langage flexible et indulgent qui permet une grande variété de choix stylistiques.

Google et Airbnb ont deux des guides de style les plus populaires. Je vous recommande vivement de consulter les deux si vous passez beaucoup de temps à écrire JS.

Voici treize de ce que je pense être les règles les plus intéressantes et pertinentes du guide de style JS de Google.

Ils traitent de tout, des questions très controversées (tabulations contre espaces, et la question controversée de la façon dont les points-virgules devraient être utilisés), à quelques spécifications plus obscures qui m'ont surpris. Ils vont certainement changer la façon dont j'écris ma JS à l'avenir.

Pour chaque règle, je vais donner un résumé de la spécification, suivi d'une citation à l'appui du guide de style qui décrit la règle en détail. Le cas échéant, je vais également fournir un exemple du style dans la pratique, et le comparer avec du code qui ne suit pas la règle.

Utilisez des espaces, pas des tabulations

Hormis la séquence de fin de ligne, le caractère d'espace horizontal ASCII (0x20) est le seul caractère d'espacement qui apparaît n'importe où dans un fichier source. Cela implique que… Les caractères de tabulation ne sont pas utilisés pour l'indentation.

Le guide spécifie plus tard que vous devez utiliser deux espaces (et non quatre) pour l'indentation.

// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}

Les points-virgules SONT obligatoires

Chaque instruction doit se terminer par un point-virgule. Il est interdit de se fier à l'insertion automatique de points-virgules.

Bien que je ne puisse pas imaginer pourquoi quiconque est opposé à cette idée, l'utilisation cohérente des points-virgules dans JS est en train de devenir le nouveau débat «espaces contre tabulations». Google se prononce fermement ici pour défendre le point-virgule.

// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father = 'vader')
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father = 'vader';});

N'utilisez pas (encore) de modules ES6

N'utilisez pas encore les modules ES6 (c'est-à-dire les mots export- importclés et ), car leur sémantique n'est pas encore finalisée. Notez que cette politique sera revue une fois que la sémantique sera entièrement standard.
// Don't do this kind of thing yet:
//------ lib.js ------export function square(x) { return x * x;}export function diag(x, y) { return sqrt(square(x) + square(y));}//------ main.js ------import { square, diag } from 'lib';

L'alignement horizontal est déconseillé (mais pas interdit)

Cette pratique est autorisée, mais elle est généralement déconseillée par Google Style. Il n'est même pas nécessaire de maintenir l'alignement horizontal dans les endroits où il était déjà utilisé.

L'alignement horizontal consiste à ajouter un nombre variable d'espaces supplémentaires dans votre code, pour que certains jetons apparaissent directement sous certains autres jetons sur les lignes précédentes.

// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};

N'utilisez plus var

Déclarez toutes les variables locales avec soit constou let. Utilisez const par défaut, sauf si une variable doit être réaffectée. Le varmot clé ne doit pas être utilisé.

Je vois encore des gens utiliser vardans des exemples de code sur StackOverflow et ailleurs. Je ne peux pas dire s'il y a des gens là-bas qui plaideront en faveur de cela, ou si c'est juste un cas de vieilles habitudes qui meurent dur.

// badvar example = 42;
// goodlet example = 42;

Les fonctions fléchées sont préférées

Les fonctions de flèche fournissent une syntaxe concise et résolvent un certain nombre de difficultés avec this. Préférez les fonctions fléchées au functionmot - clé, en particulier pour les fonctions imbriquées

Je vais être honnête, je pensais juste que les fonctions des flèches étaient géniales parce qu'elles étaient plus concises et plus agréables à regarder. Il s'avère qu'ils servent également un objectif assez important.

// bad[1, 2, 3].map(function (x) { const y = x + 1; return x * y;});// good[1, 2, 3].map((x) => { const y = x + 1; return x * y;});

Utilisez des chaînes de modèle au lieu de la concaténation

Utilisez des chaînes de modèle (délimitées par `) sur la concaténation de chaînes complexes, en particulier si plusieurs chaînes littérales sont impliquées. Les chaînes de modèle peuvent s'étendre sur plusieurs lignes.
// badfunction sayHi(name) { return 'How are you, ' + name + '?';}// badfunction sayHi(name) { return ['How are you, ', name, '?'].join();}// badfunction sayHi(name) { return `How are you, ${ name }?`;}// goodfunction sayHi(name) { return `How are you, ${name}?`;}

N'utilisez pas de continuations de ligne pour les longues chaînes

N'utilisez pas de continuations de ligne (c'est-à-dire, de terminer une ligne à l'intérieur d'un littéral de chaîne par une barre oblique inverse) dans des littéraux de chaîne ordinaires ou de modèle. Même si ES5 le permet, cela peut entraîner des erreurs délicates si un espace blanc à la fin vient après la barre oblique, et est moins évident pour les lecteurs.

Il est intéressant de noter qu'il s'agit d'une règle sur laquelle Google et Airbnb ne sont pas d'accord (voici les spécifications d'Airbnb).

Bien que Google recommande de concaténer des chaînes plus longues (comme indiqué ci-dessous), le guide de style d'Airbnb recommande essentiellement de ne rien faire et d'autoriser les longues chaînes à continuer aussi longtemps que nécessaire.

// bad (sorry, this doesn't show up well on mobile)const longString = 'This is a very long string that \ far exceeds the 80 column limit. It unfortunately \ contains long stretches of spaces due to how the \ continued lines are indented.';
// goodconst longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.';

«For… of» est le type préféré de «boucle for»

Avec ES6, le langage dispose désormais de trois types de forboucles différents. Tous peuvent être utilisés, cependant for- les ofboucles doivent être préférées lorsque cela est possible.

C'est étrange si vous me le demandez, mais j'ai pensé l'inclure car il est assez intéressant que Google déclare un type de forboucle préféré .

J'avais toujours l'impression que les for... inboucles étaient meilleures pour les objets, alors qu'elles for... ofétaient mieux adaptées aux tableaux. Une situation de type «bon outil pour le bon travail».

Bien que la spécification de Google ici ne contredit pas nécessairement cette idée, il est toujours intéressant de savoir qu'ils ont une préférence pour cette boucle en particulier.

N'utilisez pas eval ()

N'utilisez pas evalou le Function(...string)constructeur (sauf pour les chargeurs de code). Ces fonctionnalités sont potentiellement dangereuses et ne fonctionnent tout simplement pas dans les environnements CSP.

La page MDN pour a eval()même une section intitulée "Ne pas utiliser eval!"

// badlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"eval( 'var result = obj.' + propName );
// goodlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a

Les constantes doivent être nommées ALL_UPPERCASE séparées par des traits de soulignement

Les noms constants utilisent CONSTANT_CASE: toutes les lettres majuscules, avec des mots séparés par des traits de soulignement.

Si vous êtes absolument sûr qu'une variable ne doit pas changer, vous pouvez l'indiquer en mettant en majuscule le nom de la constante. Cela rend évidente l'immuabilité de la constante lorsqu'elle est utilisée dans tout votre code.

Une exception notable à cette règle est si la constante a une portée fonction. Dans ce cas, il doit être écrit en camelCase.

// badconst number = 5;
// goodconst NUMBER = 5;

Une variable par déclaration

Chaque déclaration de variable locale ne déclare qu'une seule variable: les déclarations telles que let a = 1, b = 2;ne sont pas utilisées.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Utilisez des guillemets simples et non des guillemets doubles

Les littéraux de chaîne ordinaires sont délimités par des guillemets simples ( '), plutôt que des guillemets doubles ( "). Conseil: si une chaîne contient un caractère guillemet simple, envisagez d'utiliser une chaîne de modèle pour éviter d'avoir à échapper le guillemet.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ain\u0027t so.';
// goodlet directive = 'No identification of self or mission.';
// goodlet saying = `Say it ain't so`;

Une note finale

Comme je l'ai dit au début, ce ne sont pas des mandats. Google n'est que l'un des nombreux géants de la technologie, et ce ne sont que des recommandations.

Cela dit, il est intéressant de regarder les recommandations de style émises par une entreprise comme Google, qui emploie beaucoup de personnes brillantes qui passent beaucoup de temps à écrire un excellent code.

You can follow these rules if you want to follow the guidelines for ‘Google compliant source code’ — but, of course, plenty of people disagree, and you’re free to brush any or all of this off.

I personally think there are plenty of cases where Airbnb’s spec is more appealing than Google’s. No matter the stance you take on these particular rules, it is still important to keep stylistic consistency in mind when write any sort of code.