Guide de style SQL : bonnes pratiques de formatage

Un guide de style SQL est un ensemble de conventions qui rendent les requêtes lisibles et maintiennent les diffs d’une équipe cohérents. SQL, lui, s’en moque : les mots-clés sont insensibles à la casse et les espaces sont ignorés, si bien que SELECT, select et SeLeCt s’exécutent de la même façon, et qu’une requête tenant sur une seule ligne de 200 caractères renvoie exactement les mêmes lignes que la même requête étalée sur vingt lignes indentées. Le style ne concerne donc que les humains qui reliront la requête plus tard.

Si vous avez juste besoin d’une requête propre tout de suite, collez-la dans le Formateur SQL, choisissez votre dialecte et copiez le résultat. Mais comprendre les règles qui sous-tendent ce résultat est ce qui vous permet de fixer un standard d’équipe plutôt que d’en débattre à chaque pull request. Ce guide passe en revue les choix qui comptent : la casse des mots-clés, l’indentation et les sauts de ligne, le nommage, les particularités propres aux dialectes, et la manière d’automatiser le tout.

Un mot avant d’entrer dans le détail. Comme SQL ignore les espaces et la casse, aucune de ces règles n’est imposée par la base de données : elles servent les humains qui lisent, relisent et maintiennent la requête. Deux conséquences en découlent. D’abord, il existe rarement une unique réponse « correcte » ; la plupart de ces décisions reviennent à choisir une convention raisonnable et à l’appliquer partout. Ce guide signale où se situent les vrais compromis au lieu de prétendre qu’un style gagne d’emblée. Ensuite, ces conventions n’apportent de valeur que lorsqu’on les applique de façon cohérente, et c’est pourquoi chaque section retombe sur la même conclusion : décidez une fois, puis laissez un outil l’imposer.

Pourquoi le formatage SQL compte

L’argument le plus net en faveur du formatage apparaît lors de la revue de code. Un ORM ou une étape de build émet souvent les requêtes sur une seule ligne ininterrompue :

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by orders desc

Personne ne peut relire ça. Reformatée, la structure est évidente et le diff se relit ligne par ligne :

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Le débogage en profite tout autant. Quand vous copiez une requête sur une seule ligne depuis un journal de requêtes lentes et qu’elle comporte trois jointures et un WHERE enchevêtré, la formater d’abord transforme « où est le bug » en un coup d’œil de trente secondes. Le prédicat fautif passe sur sa propre ligne, les jointures s’empilent, et un produit cartésien accidentel ou un filtre oublié saute aux yeux au lieu de rester enfoui dans un mur de texte. La même astuce aide quand vous lisez du SQL généré par un autre système : les générateurs de requêtes et les outils de reporting sont réputés pour produire un résultat correct mais illisible.

La cohérence est le bénéfice le plus discret, et avec le temps le plus précieux. Quand tout le monde formate de la même façon, les diffs ne montrent que ce qui a réellement changé, une nouvelle colonne ou un filtre ajusté, au lieu du bruit né de la préférence d’espacement de l’un qui se heurte à celle de l’autre. L’attention d’un relecteur est limitée, et la dépenser sur des espaces redisposés est du gaspillage. Un formatage cohérent facilite aussi l’arrivée des nouveaux : une recrue lit des requêtes qui se ressemblent toutes, apprend une fois la forme adoptée par l’équipe et l’applique partout. Rien de tout cela n’exige de formater à la main, sujet de la dernière section : vous décidez des règles, un outil les applique.

Un invariant sous-tend tout cela, et il vaut la peine de l’énoncer clairement parce qu’il revient tout au long de ce guide : le formatage ne modifie que les espaces, les sauts de ligne, la casse des mots-clés et les commentaires. Il ne change jamais la logique de la requête ni ses résultats. Une requête formatée est la même requête. C’est pourquoi vous pouvez passer en toute sécurité la version brouillonne ci-dessus dans le Formateur SQL sans vous soucier de ce qu’elle renvoie.

Casse des mots-clés — MAJUSCULES vs minuscules

Le plus vieux débat de tout guide de style SQL porte sur la question de savoir si les mots-clés réservés doivent être en UPPERCASE ou en lowercase. Les deux sont valides, parce que SQL est insensible à la casse pour les mots-clés. Le désaccord porte sur la lisibilité, et il vaut la peine de comprendre les deux camps avant de trancher.

Les arguments pour les mots-clés en MAJUSCULES

L’argument traditionnel est le contraste visuel. Écrire SELECT, FROM, WHERE, JOIN et GROUP BY en capitales fait ressortir les mots-clés par rapport aux noms de tables et de colonnes en minuscules, de sorte que vous pouvez parcourir la forme d’une requête, ses clauses et sa structure, sans dépendre d’un éditeur pour les colorer.

Cela compte plus qu’il n’y paraît, car le SQL transite par bien des endroits dépourvus de coloration syntaxique : fichiers de log, fils d’e-mails, descriptions de pull request, un diff en texte brut, un message Slack, un tableau de bord de supervision. Là, les mots-clés en majuscules sont à peu près la seule chose qui maintient la structure lisible. Ôtez la coloration et select id from users where active n’est plus qu’une bouillie de mots en minuscules, tandis que SELECT id FROM users WHERE active se lit toujours comme une requête au premier coup d’œil. C’est la convention des anciens guides de style, de la documentation des bases de données et de presque tous les manuels de SQL, ce qui explique aussi pourquoi beaucoup de développeurs trouvent les mots-clés en majuscules plus familiers, même quand leur éditeur les colorerait de toute façon.

Les arguments pour les mots-clés en minuscules

Le contre-argument moderne est que la coloration syntaxique a résolu le problème du contraste. Chaque éditeur et chaque IDE colore les mots-clés distinctement, donc les mettre en capitales est redondant, et pour certains lecteurs le tout-majuscules revient à crier. C’est aussi un peu plus rapide à taper, sans avoir à atteindre la touche Maj sur chaque mot-clé.

Le style en minuscules a pris de l’élan dans le monde de l’analytics engineering. La communauté dbt et plusieurs guides de style d’équipe souvent cités adoptent les mots-clés en minuscules par défaut, au motif que la coloration porte le poids visuel et que les minuscules rendent la requête plus calme à lire. Un point plus subtil joue en leur faveur : les mots-clés en minuscules se situent au même niveau visuel que vos noms de tables et de colonnes en snake_case, de sorte que la requête se lit comme un seul bloc de texte cohérent plutôt que comme deux registres qui se disputent l’attention, des mots-clés qui crient face à des identifiants discrets. Qualité ou défaut, c’est typiquement le genre de chose sur laquelle les équipes divergent, et cela mène droit au seul verdict qui tienne.

Le verdict — la cohérence l’emporte sur le choix

Voici la partie qui compte vraiment : celui des deux que vous choisissez importe bien moins que le fait d’en choisir un et de l’imposer. Une base de code où la moitié des requêtes crient SELECT et l’autre moitié chuchotent select est le pire des cas, car l’incohérence elle-même devient du bruit. Une casse mélangée au sein d’une même requête est encore pire.

La cohérence l’emporte pour une raison mécanique, pas esthétique. Une casse incohérente fait mentir les diffs : un relecteur voit une ligne « modifiée » qui n’est en réalité que le reformatage d’un mot-clé par quelqu’un, et le vrai changement se cache dans le bruit. Le grep et la recherche deviennent eux aussi moins fiables quand le même mot-clé apparaît sous trois casses. Un style unique et imposé supprime toute cette charge au prix d’une seule décision. Décidez donc en équipe, écrivez-le noir sur blanc, et laissez un outil l’imposer plutôt que de compter sur la discipline. Le Formateur SQL propose un contrôle Keywords avec trois options (UPPERCASE, lowercase et Preserve) pour normaliser un lot de requêtes historiques vers un seul style en un clic. La même requête, rendue des deux façons :

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Choisissez celui que votre équipe préfère. Le point essentiel est que toutes vos requêtes s’y conforment.

Indentation et sauts de ligne

La casse décide de l’apparence des mots-clés. L’indentation et les sauts de ligne décident de la façon dont la logique de la requête se projette sur la page, et c’est là que se loge l’essentiel de la lisibilité.

Le style « rivière » vs le style en blocs

Le célèbre sqlstyle.guide de Simon Holywell a popularisé le style « rivière », où les mots-clés sont alignés à droite de sorte qu’un canal vertical d’espaces s’écoule au milieu de la requête :

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

L’attrait, c’est que SELECT, FROM et WHERE s’alignent sur leur bord droit et que la liste de colonnes se place proprement à droite de la rivière. Les inconvénients sont pratiques, en revanche. L’alignement dépend de la longueur de votre mot-clé le plus long, si bien qu’ajouter un LEFT JOIN peut vous forcer à tout réindenter ; c’est pénible à maintenir à la main ; et cela produit des diffs bruyants, parce que changer la longueur d’un mot-clé décale les espaces sur les lignes voisines.

Le style en blocs (ou aligné à gauche) commence chaque clause majeure à la marge de gauche, sur sa propre ligne, et indente le contenu de la clause :

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

C’est le choix par défaut le plus répandu et celui que la plupart des outils produisent, parce qu’il est stable : ajouter une clause ne redispose jamais les lignes au-dessus, donc les diffs restent petits et la mise en page survit au formatage automatisé. Le style rivière optimise l’apparence d’une requête finie prise isolément ; le style en blocs optimise la façon dont les requêtes évoluent dans le temps et dont elles se relisent dans un gestionnaire de versions. Pour tout ce qui vit dans un dépôt et se fait éditer, le style en blocs est le pari le plus sûr, et c’est celui que suppose le reste de ce guide.

Combien d’espaces — 2 vs 4 vs tabulations

Une fois que vous indentez, il faut décider jusqu’où. Les trois réponses courantes ont chacune leur logique :

• 2 espaces : le choix par défaut le plus courant. Il garde les diffs compacts et empêche les requêtes imbriquées de filer hors du bord droit de l’écran.
• 4 espaces : davantage de séparation visuelle à chaque niveau d’imbrication, ce qui aide dans les requêtes à sous-requêtes profondes ou à nombreux niveaux de CTE.
• Tabulations : chaque développeur choisit sa propre largeur d’affichage sans modifier le fichier.

Il n’y a pas de réponse universellement correcte ici, ce qui est exactement la raison pour laquelle le Formateur SQL expose un contrôle Indent avec les trois (2 spaces, 4 spaces, Tab). Choisissez-en un et appliquez-le partout.

Où couper les lignes

La largeur d’indentation est la partie facile. La décision à plus fort impact est de savoir où insérer les sauts de ligne :

• Colonnes du SELECT : une colonne par ligne pour tout ce qui n’est pas trivial, de sorte qu’ajouter ou retirer une colonne ne touche qu’une seule ligne dans le diff. Les requêtes très courtes peuvent rester sur une seule ligne.
• FROM et JOIN : démarrez chaque jointure sur sa propre ligne, avec la condition ON placée à la suite ou indentée en dessous. Cela garde le graphe des jointures lisible.
• WHERE : mettez chaque AND / OR sur sa propre ligne pour que la logique booléenne se lise de haut en bas. Pour des conditions mêlant AND/OR, parenthésez et indentez les groupes afin que la précédence soit explicite au lieu d’être quelque chose que le lecteur doive reconstituer.

Ce sont des recommandations, pas des lois. Un SELECT id FROM users WHERE id = 1 n’a pas besoin de cinq lignes, et le forcer à s’étaler nuit à la lisibilité plus qu’il ne l’aide. La règle pratique : coupez quand la requête a plus d’une ou deux colonnes, plus d’une table, ou plus d’une condition. En dessous, une seule ligne est plus claire ; au-dessus, coupez sans hésiter. Un formateur encode un seuil raisonnable à votre place, mais en comprendre le principe évite que le résultat vous surprenne.

Appliquées à la requête brouillonne d’une seule ligne vue plus haut, ces règles produisent une disposition où chaque clause et chaque jointure est visible d’un coup d’œil :

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Virgules en tête vs virgules en fin

Une question plus mineure mais persistante : où placer la virgule dans une liste de colonnes multiligne ?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Les virgules en tête ont un avantage réel : ajouter ou retirer une colonne ne change qu’une seule ligne, et une virgule manquante est facile à repérer parce que la ligne fautive ressort. Les virgules en fin se lisent plus naturellement et sont nettement plus répandues en pratique. Les deux conviennent : choisissez-en une, et laissez le formateur l’appliquer pour que personne n’ait plus à y penser.

Conventions de nommage des tables et des colonnes

Le formatage régit les espaces ; le nommage régit les identifiants eux-mêmes, et un guide de style est incomplet sans lui.

Le standard de fait pour les identifiants SQL est le snake_case : tout en minuscules, les mots séparés par des tirets bas, comme user_id, created_at, order_items. Il mérite ce statut pour une raison concrète, pas par simple habitude : les identifiants en snake_case n’ont jamais besoin de guillemets et se comportent de manière cohérente d’un dialecte à l’autre, tandis que le camelCase (courant dans le code applicatif) entre en collision avec la façon dont les bases de données replient la casse, ce que nous verrons dans un instant.

Voyons en quoi cela diffère du code applicatif. Dans la plupart des langages de programmation, le code environnant contrôle les identifiants, et le camelCase ou le PascalCase est la norme. Les identifiants SQL, en revanche, sont interprétés par les propres règles de repli de casse de la base de données, et ce sont précisément ces règles qui rendent les noms en casse mixte fragiles. Le snake_case esquive tout le problème : il n’y a pas de casse à replier, aucune raison de mettre des guillemets, et rien qui se comporte différemment d’un moteur à l’autre.

Quelques conventions supplémentaires qui apparaissent dans presque tous les guides de style SQL :

• Noms de tables au singulier vs au pluriel est une vraie ligne de partage. users (pluriel, « la table contient des utilisateurs ») et user (singulier, « chaque ligne est un utilisateur ») ont tous deux leurs partisans. Comme pour la casse, le choix importe moins que de l’appliquer de façon cohérente à toutes les tables.
• Évitez les mots réservés comme identifiants. Nommer une colonne order, user ou table vous oblige à la mettre entre guillemets partout et invite des erreurs déroutantes. Optez plutôt pour order_id ou account.
• Gardez un nommage de clés cohérent. Une clé primaire appelée id et des clés étrangères nommées <referenced_table>_id (comme user_id) rendent les jointures prévisibles et auto-documentées.

Un piège mord régulièrement les équipes qui nomment les colonnes de base de données comme elles nomment les variables applicatives. Dans PostgreSQL, un identifiant sans guillemets est replié en minuscules, donc SELECT userId FROM t cherche en réalité une colonne nommée userid. Dès que vous le mettez entre guillemets ("userId"), la base de données préserve la casse et traite "userId" et userid comme deux colonnes différentes :

-- Crée une colonne dont le vrai nom est en minuscules « userid »
CREATE TABLE t (userId integer);

-- Ces deux requêtes fonctionnent — le nom a été replié en minuscules
SELECT userId FROM t;
SELECT userid FROM t;

-- Celle-ci échoue : « column "userId" does not exist »
-- Les guillemets imposent une correspondance exacte, sensible à la casse
SELECT "userId" FROM t;

Notez que les différentes bases de données replient la casse dans des directions différentes : Oracle replie les identifiants sans guillemets en majuscules, plusieurs autres en minuscules, de sorte que les identifiants en casse mixte avec guillemets ne sont même pas portables. La voie propre est d’éviter entièrement les identifiants en casse mixte entre guillemets et de s’en tenir au snake_case, qui contourne tout le problème et garde votre schéma lisible dans chaque dialecte.

Pour une comparaison plus poussée de camelCase, snake_case et kebab-case, y compris le moment où chacun est le bon choix, dans le code comme dans les données, voyez le guide des conventions de nommage.

Formater à travers les dialectes SQL

Tout ce qui précède est largement indépendant du dialecte : la casse, l’indentation, les sauts de ligne et le nommage s’appliquent quelle que soit la base de données visée. Mais « formate ce SQL » se heurte à un mur dès l’instant où votre requête utilise une syntaxe propre à une base de données, parce qu’un parseur générique qui ne reconnaît pas cette syntaxe va la massacrer : il peut couper un token au mauvais endroit, mal lire un opérateur, ou prendre un caractère de citation pour un délimiteur de chaîne et avaler la moitié de la requête. D’où l’intérêt d’un formatage qui connaît le dialecte, et la raison pour laquelle le formateur vous demande de choisir d’abord une base de données au lieu de deviner. Les différences ci-dessous sont celles que vous rencontrez le plus souvent dans les requêtes du quotidien.

Voici les écarts de syntaxe les plus courants d’un dialecte à l’autre :

Opération	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Concaténation de chaînes	|| ou CONCAT()	CONCAT()	+ ou CONCAT()	|| ou CONCAT()	||
Valeur de repli pour NULL	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Limitation des lignes	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Mise entre guillemets des identifiants	guillemets doubles ("…")	accents graves	crochets ([…])	guillemets doubles ("…")	guillemets doubles ("…")

Concaténation de chaînes et gestion des NULL

Deux des opérations les plus courantes du quotidien s’écrivent différemment selon les dialectes.

Concaténation de chaînes :

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

Valeurs de repli pour NULL :

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Un formateur réglé sur le mauvais dialecte peut ne pas comprendre ISNULL ou l’opérateur || et mal analyser la requête environnante.

Limitation de lignes et citation des identifiants

Limiter les lignes de résultat est l’un des morceaux de syntaxe les plus divergents selon les dialectes :

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

La citation des identifiants se divise elle aussi en trois. Quand vous devez mettre un identifiant entre guillemets, généralement pour utiliser un mot réservé ou préserver la casse, le délimiteur dépend de la base de données :

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Un formateur qui croit que les accents graves de MySQL sont des délimiteurs de chaîne, ou que les crochets de T-SQL sont autre chose, produira un résultat cassé. Le réglage du dialecte est ce qui lui indique qui est quoi. C’est aussi pourquoi copier-coller une requête d’une base à une autre est rarement un simple échange : la même intention logique (concaténer deux chaînes, se rabattre sur NULL, limiter à dix lignes, mettre un mot réservé entre guillemets) s’écrit de quatre façons différentes selon les dialectes, et seul le parseur qui connaît votre base de données peut la reformater sans la corrompre.

Pourquoi le formatage conscient du dialecte compte

C’est pourquoi le Formateur SQL est livré avec neuf dialectes (PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB et Standard SQL) plutôt qu’avec un unique mode générique. Sélectionner le bon signifie que le parseur traite correctement les chaînes à guillemets dollar et les casts :: de PostgreSQL, les identifiants entre crochets et le TOP de T-SQL, les fonctions propres aux entrepôts de BigQuery et Snowflake, ainsi que les règles de citation ci-dessus, au lieu de deviner et de se tromper. Choisissez votre base de données réelle dans le menu déroulant avant de formater, et le résultat revient correct et idiomatique.

Automatiser le formatage SQL

Lire les règles est une chose ; personne ne devrait les appliquer à la main. Tout l’intérêt d’un guide de style est qu’une machine l’impose. Il y a trois endroits où brancher le formatage, selon la quantité de friction que vous voulez supprimer.

Dans votre éditeur (formatage à l’enregistrement)

L’option la moins coûteuse est de formater automatiquement à chaque enregistrement. VS Code dispose d’extensions de formatage SQL qui s’exécutent à l’enregistrement, et JetBrains DataGrip ainsi que les outils de base de données d’autres IDE embarquent un formateur intégré que vous pouvez lier à un raccourci clavier ou à un hook d’enregistrement. Une fois en place, vos requêtes ne sont tout simplement jamais non formatées, sur le modèle de Prettier pour JavaScript ou de gofmt pour Go. Le hic, c’est que les réglages de l’éditeur vivent sur la machine de chaque développeur, donc le formatage à l’enregistrement garde votre SQL propre mais ne garantit pas, à lui seul, celui du reste de l’équipe. Pour cela, il faut la couche suivante.

En CI avec un linter

Pour imposer le style à toute une équipe, déplacez la vérification dans l’intégration continue. Un linter SQL comme sqlfluff lint et corrige automatiquement : vous encodez vos règles (dialecte, casse des mots-clés, indentation, placement des virgules) dans un fichier de configuration .sqlfluff, vous lancez sqlfluff lint pour signaler les infractions et sqlfluff fix pour les réparer, et vous faites échouer en CI toute pull request qui s’écarte du style convenu. C’est la même idée qu’ESLint ou Prettier verrouillant un dépôt front-end : le style cesse d’être un commentaire de revue que quelqu’un doit penser à laisser et devient une vérification réussie ou échouée que la machine n’oublie jamais. Le bénéfice, c’est que les débats sur le style ont lieu une fois, au moment d’écrire la configuration, au lieu d’à chaque pull request.

Formatage ponctuel en ligne

Parfois, vous avez juste une requête moche et aucune envie de rien installer : un extrait tiré d’un log, le message Slack d’un collègue, une requête que vous collez dans une documentation. Pour cela, collez-la dans le Formateur SQL, choisissez le dialecte, la casse et l’indentation, et copiez le résultat propre.

Le détail de la confidentialité compte ici, et on l’oublie facilement. Beaucoup de formateurs en ligne envoient le texte que vous collez à un serveur pour faire le travail, ce qui veut dire qu’une copie de votre requête (noms de tables, noms de colonnes, parfois des valeurs littérales issues d’un incident de production) quitte votre machine. Le Formateur SQL s’exécute entièrement dans votre navigateur, si bien que votre SQL n’est jamais téléversé nulle part. Vous pouvez donc formater sans risque des requêtes qui touchent des schémas de production ou une logique propriétaire, soit exactement la situation où vous voulez le plus un formatage propre et le moins confier votre requête à un tiers. Si vous jonglez avec d’autres formats dans le même flux de travail, le Formateur JSON, de la même famille, fonctionne pareil : même traitement dans le navigateur, même copie en un clic.

Les trois approches ne s’excluent pas, et la meilleure configuration les combine souvent : le formatage à l’enregistrement pour la boucle rapide pendant que vous écrivez, un linter en CI comme filet de sécurité qui impose le standard d’équipe, et un formateur en ligne pour les extraits jetables qui ne touchent jamais votre dépôt. Quel que soit votre choix, l’invariant tient une dernière fois : aucun de ces outils ne change ce que fait votre requête. Ils réagencent les espaces, les sauts de ligne, la casse et les commentaires, et rien d’autre.

Foire aux questions

Les mots-clés SQL doivent-ils être en majuscules ou en minuscules ?

Les deux sont valides, parce que les mots-clés SQL sont insensibles à la casse. Les MAJUSCULES font ressortir les mots-clés dans les environnements sans coloration syntaxique, comme les logs et les diffs ; les minuscules sont plus faciles à taper et conviennent aux éditeurs modernes qui colorent déjà les mots-clés. Ce qui compte vraiment, c’est que toute l’équipe en choisisse un et qu’un formateur l’impose. La casse mélangée est le pire des choix.

Quelle est la meilleure indentation pour SQL ?

Deux espaces est le choix par défaut le plus courant et garde les diffs compacts ; quatre espaces rendent les requêtes profondément imbriquées plus faciles à lire ; les tabulations laissent chaque développeur choisir sa propre largeur d’affichage. Il n’y a pas de réponse unique et correcte : choisissez-en une et appliquez-la de façon cohérente dans toute l’équipe. La plupart des formateurs SQL, y compris celui-ci, prennent en charge les trois options.

Comment formater du SQL automatiquement ?

Il y a trois façons de formater du SQL automatiquement : le formatage à l’enregistrement dans votre éditeur (VS Code ou DataGrip), un linter en CI comme sqlfluff qui corrige automatiquement le style, ou un formateur SQL en ligne pour un collage ponctuel. La voie en ligne est la plus rapide car elle ne nécessite aucune installation : il suffit de coller, de choisir votre dialecte et de copier le résultat.

Dois-je utiliser des virgules en tête ou en fin en SQL ?

Les virgules en tête (virgule au début de chaque ligne) donnent des diffs plus propres lors de l’ajout ou du retrait de colonnes et rendent une virgule manquante facile à repérer ; les virgules en fin (virgule à la fin) se lisent plus naturellement et sont plus répandues. Les deux sont acceptables dans tout guide de style SQL ; l’essentiel est d’en choisir une et de laisser un formateur l’appliquer automatiquement.

Le formatage SQL change-t-il la façon dont la requête s’exécute ?

Non. Le formatage SQL ne modifie que les espaces, les sauts de ligne, la casse des mots-clés et les commentaires ; il ne change jamais la logique de la requête. Une requête formatée renvoie exactement les mêmes résultats que l’originale, c’est pourquoi il est tout à fait sûr d’embellir même des requêtes de production avant de les relire ou de les exécuter.

Quelle convention de nommage utiliser pour les tables et les colonnes SQL ?

Le snake_case, tout en minuscules avec des tirets bas, est le standard de fait pour les noms de tables et de colonnes SQL parce qu’il évite les guillemets et reste sûr d’un dialecte à l’autre. Gardez un nommage cohérent pour les clés primaires (id) et les clés étrangères (user_id), et évitez d’utiliser des mots réservés comme order ou user en tant qu’identifiants pour ne pas vous compliquer la vie avec les guillemets.

Comment formater du SQL pour un dialecte spécifique comme PostgreSQL ou T-SQL ?

Sélectionnez d’abord le dialecte correspondant dans le formateur. Le mode PostgreSQL traite correctement les casts :: et les chaînes à guillemets dollar ; le mode SQL Server (T-SQL) comprend les [identifiants] entre crochets et le TOP. Choisir le mauvais dialecte laisse un parseur générique massacrer la syntaxe propre au dialecte, alors réglez-le toujours sur votre base de données réelle avant de formater.

Existe-t-il un guide de style SQL standard ?

Il n’y a pas de standard officiel, mais plusieurs guides souvent référencés existent : le sqlstyle.guide de Simon Holywell et les guides de style publics d’équipes comme Mozilla et la communauté dbt. Leur consensus commun (indentation cohérente, identifiants en snake_case et un saut de ligne avant chaque clause majeure) est ce que ce guide codifie, et un formateur peut l’imposer à votre place.