SQL Formatter

Why the dialect changes the outcome

It looks like a cosmetic detail but it decides how the text is read. In SQL Server [Order] is a quoted column name; in MySQL square brackets delimit nothing and that same text means something else. The hash sign opens a comment in MySQL and in no other dialect. A formatter ignoring these differences would not produce an ugly query — it would produce a broken one.

How clauses are laid out

Major clauses open a line at the current depth; JOINs break onto their own line but stay aligned with the FROM above them; conditions joined by AND and OR are stacked and indented, so a WHERE with six conditions is read by scanning rather than searching. Parentheses increase indentation, because a subquery is a query inside another and the shape should say so.

Strings are left alone

Text inside quotes and block comments stays exactly as it is. That is why a real tokeniser is needed rather than a series of replacements: a keyword inside a string is content, not structure, and reformatting it would change what the query does.

The batch separator

GO is not SQL: it is a SQL Server client command marking the end of a batch. That is why it is isolated on its own line and resets indentation, rather than being treated as an ordinary keyword.

What it does not do

It formats, it does not analyse: it does not check that the query is valid, it does not know your tables and it does not rewrite your code. On very dialect-specific constructs it may lay out lines differently from how you would have: the meaning stays the same, the appearance does not.