1. Format de base

Indentation

Il est recommandé d'utiliser 4 espaces par niveau. Vous pouvez définir tab = 4 espaces dans l'éditeur pour une conversion automatique.

Points-virgules

Ne pas omettre les points-virgules afin d'éviter les erreurs d'ASI (Automatic Semicolon Insertion).

Largeur de ligne

Chaque ligne de code ne doit pas dépasser 80 caractères. Si elle est trop longue, utilisez des opérateurs pour couper manuellement la ligne.

Sauts de ligne

L'opérateur doit se trouver à la fin de la ligne précédente, et la ligne suivante doit être indentée de 2 niveaux. S'il s'agit d'une instruction d'affectation, elle doit également être alignée avec la partie après le signe égal.

Lignes vides

Les lignes vides doivent être utilisées pour séparer les déclarations de fonctions des déclarations de fonctions, les déclarations de variables des déclarations de fonctions, et les blocs logiques au sein d'une fonction.

L'auteur Nicholas suggère également de laisser une ligne vide en haut des blocs de contrôle de flux, mais l'exemple donné n'est pas très clair.

Nommer

  • Noms de variables/noms de fonctions : règle Camel, le premier mot commence par une lettre minuscule, les mots suivants commencent par une lettre majuscule, et le reste est en minuscules.
  • Noms de constantes : style C, tout en majuscules, mots séparés par des traits de soulignement.
  • Constructeurs : règle Pascal, tous les mots commencent par une lettre majuscule, et le reste est en minuscules.

Littéraux

  • Chaînes de caractères : entre guillemets doubles, utilisez l'opérateur [+] pour les sauts de ligne, n'utilisez pas le caractère d'échappement \.
  • Nombres : ne pas omettre les parties avant et après le point décimal, et ne pas utiliser la forme octale.
  • Null : ne considérer null que comme un substitut pour Object. Ne pas l'utiliser pour vérifier des paramètres, et ne pas l'utiliser pour vérifier des variables non initialisées.
  • Undefined : tous les objets doivent être initialisés à null pour distinguer undefined de non initialisé.
  • Littéraux d'objet / littéraux de tableau : ne pas utiliser l'approche par constructeur pour déclarer des objets et des tableaux.

2. Commentaires

P.-S. Il y a une explication très classique dans le livre :

Des commentaires bien rédigés aident à raconter l'histoire du code, permettant à d'autres développeurs de se plonger dans une partie de l'histoire sans avoir besoin d'en entendre le début.

Commentaires sur une seule ligne

  • Fin de ligne : séparer du code avec 1 niveau d'indentation, et il doit y avoir un espace après //.
  • Sur sa propre ligne : utilisé pour commenter le code ci-dessous, et il doit conserver la même indentation que le code commenté.
  • Début de ligne : utilisé pour commenter plusieurs lignes de code.

Commentaires multilignes

Utilisé pour encadrer de grands blocs de commentaires. Le style Eclipse est recommandé, par exemple

/*
 * comment line1
 * comment line2
 */

Remarque :

  • Laisser une ligne vide au-dessus des commentaires multilignes.
  • Laissez un espace après l'astérisque *.
  • Les commentaires multilignes doivent comporter au moins trois lignes (car aucun commentaire n'est ajouté après les première et dernière lignes).

Où ajouter des commentaires

  • Code qui ne peut pas s'expliquer de lui-même
  • Intentionnel mais semble contenir des erreurs
  • Bidouilles spécifiques au navigateur

Commentaires de documentation

Des commentaires doivent être ajoutés à chaque fonction, y compris la description, les paramètres, la valeur de retour, les erreurs levées, etc., par exemple, le style Eclipse recommandé :

/**
 * 添加指定元素到默认数组
 *
 * @method add
 * @param {Number} 将要添加的元素
 * @return {Boolean} 添加成功/失败
 * @throw {TypeError} 参数类型不匹配
 */
function add(item){
    if(typeof item === "number"){
        arr.push(item)
    }
    else{
        throw new TypeError();
    }
}

3. Instructions et expressions

Alignement des accolades

Le style en fin de ligne est recommandé, pas le style sur la ligne suivante.

Espacement des instructions de bloc

Il doit y avoir un espace avant et après les parenthèses qui suivent if, par exemple :

if (expr) {
    code
}

instruction switch

  • Indentation : le case est aligné avec le switch, le break est indenté d'un niveau.
  • Passage d'un case à l'autre (fall-through) : utilisez une ligne vide ou le commentaire //falls through pour indiquer que le passage au case suivant est intentionnel.
  • default : conservez default ou utilisez le commentaire //no default pour indiquer qu'il n'y a pas de default.

P.-S. Douglas, l'auteur de « JavaScript: The Good Parts », estime que le passage d'un case à l'autre ne devrait pas être utilisé (il l'appelle « chicken ribs » — quelque chose de peu de valeur), tandis que Nicholas pense que c'est acceptable tant que cela est expliqué par une ligne vide ou un commentaire.

Instruction with

Ne l'utilisez pas.

boucle for

Toutes les variables doivent être déclarées en haut du corps de la fonction, y compris les variables utilisées dans la partie d'initialisation de la boucle for, afin d'éviter les bogues causés par le hoisting (qui peut masquer des variables globales).

Boucle for-in

Ne l'utilisez pas pour parcourir des tableaux. Lorsque vous l'utilisez, pensez à ajouter le filtre hasOwnProperty. Si vous parcourez intentionnellement des propriétés du prototype, vous devez l'expliquer avec un commentaire.

4. Variables, fonctions, opérateurs

Déclarations de variables

Corps de fonction = déclarations de variables + déclarations de fonctions + instructions logiques. Séparez chaque partie par des lignes vides.

Déclarations de fonctions

Déclarez avant utilisation. Ne placez jamais de déclarations de fonctions à l'intérieur de branches if, car les navigateurs les comprennent différemment, et ES ne fournit pas de standard.

Appels de fonctions

N'ajoutez pas d'espaces avant ou après les parenthèses, pour éviter toute confusion avec les blocs d'instructions.

Fonctions anonymes immédiatement invoquées

Enveloppez les fonctions anonymes immédiatement invoquées dans des parenthèses pour éviter toute confusion avec les déclarations de fonctions anonymes.

Mode strict

N'activez pas le mode strict dans la portée globale. Activez-le uniquement à l'intérieur des fonctions. Pour l'activer pour plusieurs fonctions, vous pouvez utiliser une fonction anonyme immédiatement invoquée pour limiter la portée du mode strict.

Vérification d’égalité

Utilisez uniquement === et !==.

eval

N'utilisez pas eval() et new Function(). Utilisez des fonctions anonymes pour optimiser setTimeout() et setInterval().

Types enveloppes primitifs

N'utilisez pas new Boolean(), new String(), new Number().

Références

  • 《JavaScript maintenable》
  • "JavaScript: The Good Parts"

De : http://www.codeceo.com/article/javascript-code-style-guide.html