SQL Formatting and Readability

Long SQL is hard to review when it is copied from logs or generated by an ORM:

select u.id,u.email,o.total,case when o.total>100 then 'vip customer' else 'standard customer' end as segment from users u join orders o on o.user_id=u.id where o.created_at>='2026-01-01' and o.status in ('paid','refunded') order by o.created_at desc;

Formatting does not make the query correct, but it exposes structure:

• Selected columns become a list.
• Join blocks become visible.
• CASE branches become readable.
• Filters can be scanned one by one.
• Sorting and limits are easier to spot.

Useful formatting habits

For application debugging, prefer consistency over personal taste:

• Put major clauses on separate lines.
• Indent nested expressions and CASE branches.
• Keep join conditions close to their joins.
• Use keyword casing consistently inside a project.
• Avoid reformatting unrelated queries in a pull request unless the change is intentional.

Minifying has a different purpose

Minifying SQL removes unnecessary whitespace and comments for compact snippets. It is useful for config files, copied examples, or tests where a single line is easier to embed.

Do not minify SQL that humans need to review during an incident. Use readable formatting while debugging.

Key takeaway

Formatting is a thinking tool. It turns a dense string into a structure you can inspect, discuss, and safely change.

Open the SQL Formatter and compare Format vs Minify on the same query to see which version fits review or embedding.