Formateur SQL

Formater et embellir les requêtes SQL

Dialecte SQL

Mots-clés en majuscules

Comprendre Le formatage SQL

TL;DR

Le formatage SQL applique une indentation, une capitalisation et des retours à la ligne cohérents aux requêtes SQL. Un SQL lisible est un SQL que l'on peut déboguer.

Qu’est-ce que le formatage SQL ?

Le formatage SQL est la pratique consistant à appliquer une indentation, des retours à la ligne, une capitalisation et un espacement cohérents aux requêtes SQL. Bien que le moteur SQL ignore les espaces et traite SELECT et select de manière identique, les lecteurs humains ne le font pas. Une requête bien formatée communique son intention en un coup d’oeil ; une requête mal formatée dissimule les bugs.

Le SQL est souvent le code le plus long et le plus complexe que les développeurs écrivent sans l’aide du formatage automatique d’un IDE. Des requêtes de 50, 100 voire 500 lignes sont courantes en analytique, ingénierie de données et développement backend. Sans formatage cohérent, ces requêtes deviennent quasiment impossibles à revoir, déboguer ou maintenir.

Un formateur SQL automatise ce processus — il prend n’importe quel SQL syntaxiquement valide et le restructure selon un ensemble de règles, produisant une sortie propre et cohérente quelle que soit la façon dont l’entrée a été écrite.

Conventions courantes de formatage SQL

Bien qu’il n’existe pas de guide de style SQL universel unique, la plupart des équipes convergent vers des conventions similaires :

Capitalisation des mots-clés

Style	Exemple	Prévalence
Mots-clés en MAJUSCULES	`SELECT id FROM users WHERE active = 1`	Le plus courant
Mots-clés en minuscules	`select id from users where active = 1`	Courant dans les ORM
Casse mixte	`Select id From users Where active = 1`	Rare

Les mots-clés en majuscules sont la convention dominante dans la communauté SQL. Ils créent une distinction visuelle claire entre la structure SQL (SELECT, FROM, WHERE, JOIN) et les identifiants définis par l’utilisateur (noms de tables, noms de colonnes, alias).

Indentation et retours à la ligne

Les règles de formatage standard incluent :

Clauses principales sur de nouvelles lignes : Chaque clause SQL (SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT) commence sur une nouvelle ligne au niveau d’indentation de base.
Listes de colonnes indentées : Chaque colonne d’une clause SELECT obtient sa propre ligne, indentée d’un niveau.
Conditions JOIN indentées : La clause ON d’un JOIN est indentée sous le mot-clé JOIN.
Conditions WHERE alignées : Les conditions multiples d’une clause WHERE sont indentées et préfixées par AND ou OR au début de chaque ligne.
Sous-requêtes indentées : Les sous-requêtes sont indentées d’un niveau supplémentaire et encadrées par des parenthèses sur leurs propres lignes.

Alias

Utilisez des alias de table courts et significatifs (users u ou users AS u)
Préfixez toutes les références de colonnes avec l’alias de table quand plusieurs tables sont impliquées
Placez le mot-clé AS explicitement pour plus de clarté (optionnel mais recommandé)

Différences entre dialectes

SQL n’est pas un langage unique — c’est une famille de dialectes. Chaque moteur de base de données étend le standard SQL avec une syntaxe propriétaire, et les formateurs doivent tenir compte de ces différences :

Fonctionnalité	PostgreSQL	MySQL	SQL Server	BigQuery
Guillemets de chaînes	`'text'`	`'text'` ou `"text"`	`'text'`	`'text'`
Guillemets d’identifiants	`"column"`	`column`	`[column]`	`column`
Syntaxe LIMIT	`LIMIT 10`	`LIMIT 10`	`TOP 10`	`LIMIT 10`
Type booléen	`TRUE/FALSE`	`1/0`	`1/0`	`TRUE/FALSE`
UPSERT	`ON CONFLICT`	`ON DUPLICATE KEY`	`MERGE`	`MERGE`
Support CTE	Complet	8.0+	Complet	Complet

Lors de la configuration d’un formateur SQL, spécifiez toujours le dialecte cible. Un formateur configuré pour PostgreSQL peut produire une syntaxe invalide pour MySQL et vice versa. Les formateurs modernes prennent en charge plusieurs dialectes et peuvent basculer entre eux.

Bonnes pratiques de formatage

Au-delà des conventions de base, les développeurs SQL expérimentés suivent des pratiques supplémentaires :

Une instruction par ligne pour le DDL : Les instructions CREATE TABLE, ALTER TABLE et CREATE INDEX bénéficient d’une définition de colonne par ligne.
CTE (clauses WITH) en premier : Placez les Common Table Expressions en haut de la requête, chacune avec un nom descriptif, avant le SELECT principal.
Placement cohérent des virgules : Soit des virgules en début de ligne (,name) soit des virgules en fin de ligne (name,) — choisissez un style et respectez-le. Les virgules en début de ligne facilitent la mise en commentaire des colonnes.
Alias significatifs : Évitez les alias à une seule lettre pour les requêtes complexes. Utilisez ord au lieu de o quand la requête s’étend sur plus de 50 lignes.
Commentez la logique complexe : Ajoutez des commentaires en ligne (-- explication) pour les conditions WHERE non évidentes, les calculs ou les règles métier.

Cas d’utilisation courants

Revue de code : Le SQL formaté est considérablement plus facile à revoir dans les pull requests. Les relecteurs peuvent repérer en un coup d’oeil les conditions JOIN manquantes, la logique WHERE incorrecte et les problèmes de performance.
Débogage : Quand une requête retourne des résultats inattendus, un formatage cohérent aide à isoler le problème clause par clause.
Documentation : Les requêtes formatées dans la documentation, les wikis et les runbooks sont plus accessibles aux membres de l’équipe qui ne les ont pas écrites.
Scripts de migration : Les fichiers de migration de base de données (Flyway, Liquibase, Alembic) bénéficient d’un formatage cohérent pour l’auditabilité et la clarté des rollbacks.
Analytique et reporting : Les analystes de données travaillant avec de longues requêtes analytiques s’appuient sur le formatage pour gérer la complexité à travers les jointures multi-tables, les fonctions de fenêtrage et les sous-requêtes imbriquées.

Essayez ces exemples

SELECT bien formaté avec JOINs Valide

Une requête correctement formatée avec des mots-clés en majuscules, une indentation cohérente, une colonne par ligne dans la clause SELECT et des conditions JOIN/WHERE alignées. Ce style est immédiatement lisible.

SELECT
  u.id,
  u.name,
  o.total_amount
FROM users u
INNER JOIN orders o
  ON o.user_id = u.id
WHERE u.active = 1
  AND o.created_at >= '2024-01-01'
ORDER BY o.total_amount DESC
LIMIT 100;

Requête non formatée sur une seule ligne Valide

Du SQL syntaxiquement valide qui produit le même résultat, mais compressé sur une seule ligne avec une capitalisation incohérente. Extrêmement difficile à lire, déboguer ou revoir lors d'une revue de code.

select u.id,u.name,o.total_amount from users u inner join orders o on o.user_id=u.id where u.active=1 and o.created_at>='2024-01-01' order by o.total_amount desc limit 100;