Formatage du code JavaScript : outils et standards

Ouvrez n'importe quelle pull request dont la moitié du diff est constituée de changements d'espacement, et vous ressentirez immédiatement la douleur. Les incohérences de formatage gaspillent du temps, encombrent les revues de code et créent des conflits de fusion qui n'ont rien à voir avec la logique. La solution est simple : choisir un standard de formatage, automatiser son application et ne plus jamais y penser.

Ce guide vous présente les outils et les standards qui font du formatage JavaScript un problème résolu.

Pourquoi un formatage cohérent est important

Le formatage n'est pas une question d'esthétique — c'est une question de vélocité d'équipe. Quand chaque développeur utilise des indentations, des placements d'accolades et des longueurs de lignes différents, trois choses se produisent :

Les revues de code ralentissent. Les relecteurs dépensent de l'énergie mentale à décrypter un formatage inhabituel au lieu d'évaluer la logique. Une fonction qui diffère visuellement du reste du code attire l'attention pour de mauvaises raisons.

Les conflits de fusion se multiplient. Le développeur A reformate un fichier avec des tabulations, le développeur B utilise des espaces, et Git affiche chaque ligne comme modifiée. La correction de trois lignes pour le vrai bug se retrouve noyée.

La charge cognitive augmente. Basculer entre des fichiers aux styles différents force votre cerveau à réanalyser constamment la structure. Un formatage cohérent vous permet de lire le code comme de la prose — vos yeux savent instinctivement où regarder.

La solution n'est pas de débattre du meilleur style. C'est d'en choisir un et de l'automatiser.

Les guides de style JavaScript populaires

Avant de choisir des outils, il est utile de connaître les principaux guides de style qui ont façonné les conventions de formatage en JavaScript.

Airbnb Style Guide

Le guide de style JavaScript le plus largement adopté. Il impose les points-virgules, privilégie les guillemets simples, exige les virgules finales dans les constructions multilignes et utilise une indentation de 2 espaces. La configuration ESLint (eslint-config-airbnb) regroupe des centaines de règles couvrant à la fois le formatage et la qualité du code.

// Airbnb style
const getUserData = (userId) => {
  const user = findUser(userId);
  return {
    name: user.name,
    email: user.email,
  };
};

Standard Style

Adopte l'approche inverse sur les points-virgules — aucun point-virgule, jamais. Utilise une indentation de 2 espaces et des guillemets simples. Le package standard inclut son propre linter, ce qui rend une configuration ESLint séparée inutile.

// Standard style
const getUserData = (userId) => {
  const user = findUser(userId)
  return {
    name: user.name,
    email: user.email
  }
}

Google Style Guide

Similaire à Airbnb, mais avec quelques différences au niveau des exigences JSDoc et des conventions de nommage. Utilise une indentation de 2 espaces, exige les points-virgules et privilégie les guillemets simples.

Chacun de ces guides de style a ses compromis. L'important, c'est la cohérence, pas lequel vous choisissez. Et de plus en plus, les équipes évitent tout simplement le débat en laissant Prettier décider.

Prettier : le formateur aux opinions tranchées

Prettier a révolutionné le formatage JavaScript en supprimant la plupart des décisions. Il analyse votre code sous forme d'AST (Abstract Syntax Tree) et le réécrit selon ses propres règles. Vous ne configurez pas chaque choix de formatage individuellement — vous définissez quelques options de haut niveau et Prettier se charge du reste.

Installation

npm install --save-dev prettier

Créez un fichier de configuration .prettierrc :

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always"
}

Options de configuration principales

printWidth (défaut : 80) — La longueur de ligne à partir de laquelle Prettier effectue un retour à la ligne. Ce n'est pas une limite stricte — Prettier l'utilise comme indicateur pour décider quand répartir les expressions sur plusieurs lignes. Une valeur de 100 ou 120 est courante dans les équipes disposant de grands écrans.

semi (défaut : true) — Détermine si des points-virgules sont ajoutés à la fin des instructions. Mettez la valeur à false si vous préférez le style Standard.

singleQuote (défaut : false) — Utilise des guillemets simples au lieu des guillemets doubles. La plupart des développeurs JavaScript préfèrent les guillemets simples, ce qui fait de true le réglage le plus courant.

trailingComma (défaut : "all") — Ajoute des virgules finales partout où elles sont syntaxiquement valides. Cela produit des diffs Git plus propres, car l'ajout d'un nouvel élément à une liste n'affiche qu'une seule ligne modifiée au lieu de deux.

// Sans virgules finales — l'ajout de "d" modifie deux lignes
const items = [
-  "a",
-  "b",
-  "c"
+  "a",
+  "b",
+  "c",
+  "d"
];

// Avec virgules finales — l'ajout de "d" modifie une seule ligne
const items = [
  "a",
  "b",
  "c",
+  "d",
];

arrowParens (défaut : "always") — Détermine si un paramètre unique de fonction fléchée est entouré de parenthèses. "always" donne (x) => x, "avoid" donne x => x.

Exécuter Prettier

# Formater tous les fichiers
npx prettier --write .

# Vérifier sans modifier
npx prettier --check .

# Formater des types de fichiers spécifiques
npx prettier --write "src/**/*.{js,jsx,ts,tsx}"

Créez un fichier .prettierignore pour exclure les fichiers générés :

node_modules
dist
build
coverage
*.min.js

Si vous travaillez avec du JavaScript minifié, notre Code Minifier gère correctement la minification — ne modifiez jamais du code minifié à la main.

ESLint : au-delà du formatage

ESLint remplit un rôle différent de Prettier. Alors que Prettier s'occupe de l'apparence du code, ESLint détecte son comportement. Les règles d'ESLint se divisent en deux catégories :

Règles de formatage — indentation, espacement, placement des accolades. Celles-ci chevauchent Prettier et doivent généralement être désactivées lorsque les deux outils sont utilisés ensemble.

Règles de qualité du code — variables inutilisées, code inaccessible, coercition de type implicite, gestion d'erreurs manquante. C'est là qu'ESLint excelle vraiment.

Configuration recommandée

npm install --save-dev eslint @eslint/js

Un fichier eslint.config.js minimal :

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    rules: {
      'no-unused-vars': 'warn',
      'no-console': 'warn',
      'eqeqeq': 'error',
      'no-implicit-coercion': 'error',
    },
  },
];

Pour les projets TypeScript, ajoutez typescript-eslint :

npm install --save-dev typescript-eslint

import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
);

Intégration Prettier + ESLint

Faire tourner les deux outils sans coordination crée des conflits — les règles de formatage d'ESLint s'opposent à la sortie de Prettier. La solution est eslint-config-prettier, qui désactive toutes les règles ESLint en conflit avec Prettier.

npm install --save-dev eslint-config-prettier

import js from '@eslint/js';
import prettierConfig from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  prettierConfig,
  {
    rules: {
      // Uniquement des règles de qualité du code ici
      'no-unused-vars': 'warn',
      'eqeqeq': 'error',
    },
  },
];

Avec cette configuration, Prettier gère le formatage et ESLint gère la qualité du code. Aucun conflit, aucune confusion.

EditorConfig pour la cohérence entre éditeurs

Tous les membres de votre équipe n'utilisent pas le même éditeur. EditorConfig fournit une base commune qui fonctionne avec VS Code, WebStorm, Vim, Sublime Text et la plupart des autres éditeurs.

Créez un fichier .editorconfig à la racine de votre projet :

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

EditorConfig gère les fondamentaux — indentation, fins de ligne, espaces en fin de ligne — avant même que Prettier ne s'exécute. Cela empêche le problème classique où un développeur sous Windows introduit des fins de ligne \r\n dans un projet basé sur Unix.

Git Hooks avec Husky et lint-staged

Le formatage automatisé ne fonctionne que s'il est réellement exécuté. Compter sur les développeurs pour se souvenir de lancer npx prettier --write avant chaque commit ne passe pas à l'échelle. Les Git Hooks résolvent ce problème.

Configuration

npm install --save-dev husky lint-staged
npx husky init

Ajoutez à votre package.json :

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "prettier --write",
      "eslint --fix"
    ],
    "*.{json,md,css}": [
      "prettier --write"
    ]
  }
}

Mettez à jour le hook pre-commit de Husky (.husky/pre-commit) :

npx lint-staged

Désormais, chaque commit formate automatiquement les fichiers indexés et applique les corrections ESLint. Les développeurs n'ont jamais besoin de penser au formatage — il se fait tout seul.

C'est le standard de référence pour les projets d'équipe : Prettier formate, ESLint détecte les bugs, Husky impose les deux à chaque commit.

Le débat des points-virgules

Aucune discussion sur le formatage JavaScript n'est complète sans la question des points-virgules. Voici la réponse pragmatique : cela n'a pas d'importance, tant que votre équipe est cohérente.

Pour les points-virgules : La terminaison explicite des instructions évite les cas limites de l'ASI (Automatic Semicolon Insertion). Les guides de style d'Airbnb et de Google les exigent.

Sans points-virgules : L'ASI de JavaScript gère automatiquement la terminaison. Le code est plus épuré, avec moins de bruit visuel. Le guide de style Standard les omet.

Les pièges de l'ASI dont on entend souvent parler — comme les lignes commençant par ( ou [ — sont détectés par la règle no-unexpected-multiline d'ESLint. En pratique, se passer de points-virgules avec un linting correctement configuré est parfaitement sûr.

Faites un choix, configurez l'option semi de Prettier en conséquence, et passez à autre chose. Prettier les ajoutera ou les supprimera de manière cohérente dans tous les cas.

Tabulations vs espaces en JavaScript

L'écosystème JavaScript utilise massivement les espaces — plus précisément, une indentation de 2 espaces. Ce n'est pas universel (Go utilise les tabulations, Python utilise 4 espaces), mais en JavaScript, c'est la convention largement dominante.

Pourquoi 2 espaces ? Les patterns de callbacks imbriqués et les méthodes chaînées en JavaScript créent rapidement une indentation profonde. Deux espaces gardent le code profondément imbriqué lisible sans le pousser au-delà du bord droit de l'écran.

Pourquoi pas les tabulations ? Les tabulations permettent à chaque développeur de définir sa propre largeur d'affichage, ce qui semble intéressant en théorie, mais signifie que l'alignement du code ne fonctionne plus d'un éditeur à l'autre. Avec les espaces, ce que vous voyez est ce que tout le monde voit.

Configurez cela une seule fois dans Prettier (tabWidth: 2, useTabs: false) et EditorConfig (indent_style = space, indent_size = 2), et c'est réglé.

Pièges de formatage courants

Fonctions fléchées incohérentes

// Incohérent — à éviter
const double = x => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

// Cohérent — Prettier avec arrowParens: "always"
const double = (x) => x * 2;
const add = (a, b) => a + b;
const greet = (name) => {
  return `Hello, ${name}`;
};

Style de déstructuration d'objets

// Tassé — difficile à lire
const {name,email,role} = user;

// Formaté — Prettier s'en charge automatiquement
const { name, email, role } = user;

// Multiligne pour de nombreuses propriétés
const {
  name,
  email,
  role,
  department,
  startDate,
} = user;

Organisation des instructions d'import

Prettier ne trie pas les imports — c'est une question de qualité du code, pas de formatage. Utilisez eslint-plugin-import ou le plugin simple-import-sort :

// Imports organisés
import React from 'react';
import { useState, useEffect } from 'react';

import { Button } from '@/components/Button';
import { Modal } from '@/components/Modal';

import { formatDate } from '../utils/dates';
import { validateEmail } from '../utils/validation';

Longues expressions ternaires

// Illisible sur une seule ligne
const label = isAdmin ? 'Admin Dashboard' : hasEditPermission ? 'Editor View' : 'Read Only';

// Prettier reformate en multiligne lisible
const label = isAdmin
  ? 'Admin Dashboard'
  : hasEditPermission
    ? 'Editor View'
    : 'Read Only';

Configurer un nouveau projet

Voici une checklist complète pour la mise en place d'un nouveau projet JavaScript ou TypeScript :

Installer les dépendances :

npm install --save-dev prettier eslint eslint-config-prettier husky lint-staged

Créer .prettierrc avec les préférences de votre équipe
Créer .editorconfig comme base commune entre éditeurs
Configurer ESLint avec uniquement des règles de qualité du code (pas de règles de formatage)
Mettre en place Husky + lint-staged pour l'application automatique au commit

Ajouter des scripts npm :

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "lint": "eslint .",
    "lint:fix": "eslint --fix ."
  }
}

Lancer le formatage initial sur l'ensemble de la base de code : npm run format
Commiter le code formaté en un seul commit pour pouvoir l'ignorer facilement dans git blame avec --ignore-rev

Le formatage au quotidien

Une fois votre pipeline de formatage en place, l'expérience au jour le jour change radicalement :

Écrivez le code comme vous le souhaitez. Prettier reformate à l'enregistrement ou au commit.
Les pull requests ne montrent que les changements de logique. Plus de bruit lié aux espaces.
Les nouveaux membres de l'équipe sont productifs immédiatement. Les outils imposent les standards sans qu'un document de guide de style soit nécessaire.
Les débats sur le style disparaissent. Prettier fait autorité, pas un développeur en particulier.

Quand vous avez besoin de vérifier la structure de données JSON sur lesquelles vous travaillez, notre JSON Formatter rend l'inspection facile — collez n'importe quel JSON et obtenez instantanément un formatage lisible directement dans votre navigateur.

Ressources complémentaires

Pour aller plus loin sur le formatage de code et les outils de développement :

Code Minification Guide — Apprenez quand et comment minifier du JavaScript pour la production
Naming Conventions in Programming — Des conventions de nommage cohérentes sont l'autre moitié d'un code lisible
SQL Formatting Best Practices — Appliquez la même discipline de formatage à vos requêtes de base de données

Un formatage cohérent est l'un de ces rares investissements techniques qui rapportent immédiatement et continuent de rapporter. Mettez-le en place une fois, automatisez-le, et consacrez votre énergie au code qui compte vraiment.