Formattatore SQL

Perché il dialetto cambia il risultato

Sembra un dettaglio estetico e invece decide come il testo viene letto. In SQL Server [Ordine] è un nome di colonna delimitato; in MySQL le parentesi quadre non delimitano nulla e quello stesso testo è qualcos'altro. Il cancelletto apre un commento in MySQL e in nessun altro dialetto. Un formattatore che ignorasse queste differenze non produrrebbe una query brutta: ne produrrebbe una spezzata.

Come vengono disposte le clausole

Le clausole principali aprono una riga alla profondità corrente; le JOIN vanno a capo ma restano allineate alla FROM che le precede; le condizioni unite da AND e OR si incolonnano rientrate, così una WHERE con sei condizioni si legge scorrendo invece che cercando. Le parentesi aumentano il rientro, perché una sottoquery è una query dentro un'altra e la forma dovrebbe dirlo.

Le stringhe non vengono toccate

Il testo dentro gli apici e i commenti a blocco resta esattamente com'è. È la ragione per cui serve un vero tokenizzatore e non una serie di sostituzioni: una parola chiave dentro una stringa è contenuto, non struttura, e riformattarla cambierebbe ciò che la query fa.

Il separatore di batch

GO non è SQL: è un comando del client di SQL Server che segna la fine di un lotto. Per questo viene isolato sulla propria riga e azzera il rientro, invece di essere trattato come una parola chiave qualunque.

Cosa non fa

Formatta, non analizza: non verifica che la query sia valida, non conosce le tue tabelle e non riscrive il codice. Su costrutti molto particolari di un singolo dialetto può disporre le righe in modo diverso da quello che avresti scelto: il significato resta lo stesso, l'aspetto no.