Formateur SQL

Un formateur qui met en majuscules des mots-clés en comparant des mots entiers avec une expression régulière n'a aucun moyen de savoir si une occurrence donnée de « order » est le mot-clé SQL `ORDER` (comme dans `ORDER BY`) ou une valeur de chaîne littérale qui contient ce mot — une requête filtrant des lignes `WHERE description = 'the order from stock'` a le mot « order » dans une chaîne entre guillemets, ne fonctionnant pas du tout comme mot-clé. Un formateur naïf met en majuscules chaque mot correspondant sans tenir compte du contexte, corrompant la valeur de chaîne littérale en `'the ORDER FROM stock'` et changeant silencieusement ce que la requête filtre réellement. Tokeniser correctement la requête — reconnaissant les limites des chaînes entre guillemets avant de décider ce qui compte comme mot-clé — est ce qui empêche cela, et c'est précisément le genre d'erreur qui n'apparaît qu'avec de vraies données contenant des mots qui correspondent à des mots-clés SQL, donc facile à manquer en testant avec de simples requêtes d'exemple.

Cet outil reconnaît la structure de clauses commune partagée entre PostgreSQL, MySQL, SQL Server, SQLite et Oracle — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY et leurs parents — assez bien pour indenter chaque clause sur sa propre ligne et imbriquer correctement les sous-requêtes. Il ne construit pas une compréhension complète de la grammaire entière d'une base de données précise, y compris les extensions spécifiques à un fournisseur comme la syntaxe de tableau de PostgreSQL ou le placement de la clause `TOP` de SQL Server. La conséquence pratique est que la syntaxe spécifique à un dialecte passe à travers le formateur intacte plutôt que de provoquer une erreur, mais elle ne recevra pas non plus la même indentation soignée que les clauses communes — un compromis raisonnable pour prendre en charge cinq dialectes avec un seul formateur plutôt que de nécessiter un outil séparé par moteur de base de données.

Les mots-clés SQL ne distinguent pas la casse par la spécification même du langage — `SELECT`, `Select` et `select` sont identiques pour tout moteur SQL — ce qui est précisément ce qui rend leur mise en majuscules ou minuscules une opération purement cosmétique sans aucun risque d'altérer le comportement. Il en va de même pour les espaces blancs et sauts de ligne qu'ajoute ce formateur : une requête répartie sur douze lignes indentées s'exécute de façon identique à la même requête entassée sur une seule. Rien dans le formatage ne touche les tokens réels qui déterminent quelles tables sont lues, quelles conditions filtrent les lignes, ou quelles valeurs sont insérées — seulement comment cette même requête logique est visuellement disposée pour un humain qui la lit ensuite.

Une requête générée par un ORM, exportée depuis une interface graphique de base de données, ou écrite en une seule longue ligne pendant une migration précipitée est souvent fonctionnellement correcte mais réellement difficile à relire pour une personne telle qu'écrite — une requête avec quinze jointures sans sauts de ligne rend difficile de voir quelles conditions appartiennent à quelle jointure, ou si une clause WHERE filtre la bonne table. La reformater avec chaque clause et chaque jointure sur sa propre ligne, indentée pour refléter la structure réelle de la requête, est souvent le moyen le plus rapide de vraiment comprendre ce que fait une longue requête générée avant de l'approuver en revue de code ou de déboguer pourquoi elle renvoie les mauvaises lignes.