T-SQL Formatter

Transact-SQL scripts tend to be long-lived and heavily edited: a stored procedure written in 2014, extended twice, and reformatted by whichever editor each author happened to have open. Add SQL Server Management Studio generating fully-bracketed [dbo].[TableName] references for you and lines get wide fast. This formatter lays the script back out with one clause per line and consistent indentation.

With the T-SQL dialect selected the parser recognises the things that make Transact-SQL distinct from ANSI SQL: square-bracket identifiers, TOP instead of LIMIT, @variables and #temp tables, GO batch separators, table hints, and the full MERGE statement with its several WHEN branches.

T-SQL constructs the formatter understands

• Square-bracket identifiers. [dbo].[Order Details] is one quoted identifier per part, spaces and reserved words included. Brackets are never converted to double quotes, since those only behave as identifier delimiters when QUOTED_IDENTIFIER is ON.
• GO. Kept on its own line as a batch separator. Worth knowing: GO is not T-SQL at all — the server never sees it. It is a client instruction understood by SSMS, sqlcmd and Azure Data Studio that says "send everything since the last one as a batch".
• MERGE. The USING source, the ON predicate and each WHEN MATCHED / WHEN NOT MATCHED BY TARGET / WHEN NOT MATCHED BY SOURCE branch are broken onto separate lines. A MERGE with three branches is where formatting pays for itself most obviously.
• Variables, table variables and temp tables. @cutoff, DECLARE @t TABLE (…), #session_temp and ##global_temp are all tokenised correctly rather than being split on the sigil.
• Table hints. WITH (NOLOCK), WITH (INDEX(…)) and friends are preserved verbatim. One cosmetic quirk to expect: because WITH also introduces a CTE, a hint is printed on its own line under the table it applies to. The query is unchanged, but the layout looks a little unusual.
• TOP. Recognised as a T-SQL clause. Note that TOP 50 is printed on the same line as the first selected column rather than on a line of its own — the query is correct, it is just a tighter layout than you might expect.

TOP, OFFSET/FETCH, and why LIMIT never appears

SQL Server has no LIMIT. Row limiting is SELECT TOP (n), optionally with PERCENT or WITH TIES, and it applies before the result set is handed back but is only deterministic when paired with an ORDER BY.

For true pagination, SQL Server 2012 added the ANSI form ORDER BY … OFFSET n ROWS FETCH NEXT m ROWS ONLY, which requires an ORDER BY and formats onto its own lines here. If you are porting a MySQL query, LIMIT 10 OFFSET 20 becomes OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY — and if you paste the MySQL version with the T-SQL dialect selected, the parser will tell you it does not belong.

Formatting does not make NOLOCK safe

Since WITH (NOLOCK) shows up in most SQL Server code that reaches a formatter, it is worth stating plainly: the hint means read uncommitted. It permits dirty reads, and it can also return a row twice or skip a row entirely if a page split happens mid-scan. The formatter preserves it exactly because that is its job; whether it belongs in the query is a decision for you, and READ COMMITTED SNAPSHOT is usually the better answer.

Equally, this tool does not parse execution plans or estimate cost. It is a layout tool that runs entirely in your browser and never connects to an instance.