Formateur SQL | Découpez les Requêtes Compactes en Clauses Lisibles

Collez une requête SQL sur une seule ligne issue d'un journal d'ORM ou minifiée, et cet outil la répartit ligne par ligne par clause — SELECT, FROM, WHERE, JOIN — avec une indentation de 4 espaces. Les mots réservés sont normalisés en majuscules, et plus de 100 mots-clés, littéraux de chaîne, nombres et commentaires sont colorés.

💡 À propos de cet outil

Vous ouvrez une demande de fusion et le SQL à l'intérieur tient sur une seule longue ligne. Impossible de voir où finit la condition de jointure et où commence le filtre. Cet outil trace ces frontières de clause de façon mécanique pour rendre la requête déchiffrable.

Le formatage repose sur un analyseur lexical plutôt que sur une expression régulière naïve. Les littéraux de chaîne ('...' et "...") et les commentaires (-- de ligne et /* */ de bloc) sont extraits comme des jetons distincts : leur contenu n'est donc jamais modifié, seuls les mots-clés en dehors passent en majuscules. Les clauses composées comme GROUP BY, ORDER BY et LEFT OUTER JOIN sont reconnues comme une unité et placées sur leur propre ligne. Quand une sous-requête s'ouvre par un SELECT entre parenthèses, l'indentation augmente d'un niveau puis revient en arrière à la parenthèse fermante : la profondeur d'imbrication se lit donc directement dans le retrait. Les expressions CASE indentent leurs branches WHEN / THEN / ELSE et s'alignent sur END.

Les panneaux d'entrée et de sortie sont côte à côte, ce qui permet de comparer l'original au résultat. Copiez la sortie directement dans un client SQL ou un commentaire de revue de code.

🧐 Questions fréquentes

Q. Quels dialectes SQL sont pris en charge ? R. Au-delà du SQL standard, le jeu de mots-clés couvre les identifiants entre accents graves de MySQL, RETURNING / ON CONFLICT de PostgreSQL et les termes de fonctions de fenêtrage comme OVER / PARTITION BY : plus de 100 mots réservés communs aux principaux dialectes. Les fonctions propres à un dialecte sont traitées comme des identifiants, ce qui n'affecte pas la mise en page.

Q. Un SELECT dans une chaîne sera-t-il mis en majuscules ? R. Non. Les littéraux de chaîne entre guillemets simples ou doubles et les commentaires sont isolés comme jetons distincts pendant l'analyse, et leur contenu reste tel quel.

Q. Puis-je formater plusieurs instructions à la fois ? R. Oui. Les instructions séparées par un point-virgule (;) sont chacune formatées, avec une ligne vide insérée entre elles.

Q. Puis-je changer la largeur de l'indentation ? R. Elle est fixée à 4 espaces. Ajustez-la ensuite avec la fonction rechercher-remplacer de votre éditeur si vous préférez un style à 2 espaces.

Q. Le résultat peut-il parfois être incorrect ? R. Un SQL construit par concaténation de chaînes ou parsemé de marqueurs de gabarit (comme {{ }}) s'écarte de la grammaire attendue par l'analyseur, si bien que les retours à la ligne peuvent tomber à des endroits inattendus.

📚 Le saviez-vous

L'habitude d'écrire les mots-clés SQL en majuscules remonte à l'époque où SQL fut conçu pour ignorer la casse : mettre les mots réservés en capitales était un moyen pratique de les distinguer des identifiants sur un terminal monochrome. Le SQL ANSI accepte sans problème les mots-clés en minuscules, mais beaucoup de guides de style recommandent encore les majuscules par tradition. La casse des identifiants, en revanche, est traitée différemment selon la base : PostgreSQL replie en minuscules les identifiants non entre guillemets. Un formateur qui ne met en majuscules que les mots réservés tout en préservant la casse d'origine des identifiants évite de casser ces différences.