5 SQL Formatting Rules That Make Your Queries Actually Readable

ZevinChen — Sun, 15 Mar 2026 04:49:15 +0000

We've all been there — you inherit a project, open a stored procedure, and it's one giant wall of SQL. No indentation, no structure, just chaos. Or maybe you wrote it yourself 6 months ago and now you can't even tell what it does.

After years of writing SQL professionally, here are 5 formatting rules I follow that make my queries actually readable — both for my teammates and for future me.

1. One Clause Per Line

This is the simplest rule but makes the biggest difference. Each major SQL clause gets its own line.

Bad:

SELECT u.id, u.name, u.email, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.created_at > '2024-01-01' AND u.active = 1 ORDER BY o.total DESC;

Good:

SELECT u.id, u.name, u.email, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.created_at > '2024-01-01'
  AND u.active = 1
ORDER BY o.total DESC;

Instantly more scannable. You can immediately see the tables involved, the join condition, and the filters.

2. Leading Commas in SELECT Lists

This is controversial, but hear me out. Leading commas make it trivial to comment out or add columns:

SELECT
  u.id
  , u.name
  , u.email
  , u.created_at
  -- , u.phone  (easy to toggle!)
FROM users u

When you need to remove a column, you don't have to worry about trailing comma issues. Just comment the line out.

3. Indent Subqueries and CTEs Consistently

CTEs (WITH clauses) are powerful but can get messy fast. Keep them clean:

WITH active_users AS (
  SELECT id, name, email
  FROM users
  WHERE active = 1
    AND last_login > '2024-06-01'
),
recent_orders AS (
  SELECT user_id, SUM(total) AS total_spent
  FROM orders
  WHERE created_at > '2024-01-01'
  GROUP BY user_id
)
SELECT
  au.name
  , au.email
  , ro.total_spent
FROM active_users au
JOIN recent_orders ro ON au.id = ro.user_id
ORDER BY ro.total_spent DESC;

Each CTE is a clear, self-contained block. Easy to understand, easy to debug.

4. Uppercase Keywords, Lowercase Everything Else

This creates a clear visual hierarchy:

SELECT u.name, COUNT(*) AS order_count
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE u.country = 'US'
GROUP BY u.name
HAVING COUNT(*) > 5
ORDER BY order_count DESC;

Your eyes can scan the keywords to understand the query structure without reading every detail.

5. Use a Formatter for Consistency

Even with good habits, manual formatting isn't always consistent — especially when working in a team. This is where automated formatters save you.

I've been using SQLNice recently — it's a free online SQL formatter that handles most of these rules automatically. Paste your messy query, get clean output. It's especially handy for those monster queries you inherit from legacy codebases.

Other options include built-in IDE formatters (DataGrip, DBeaver) and CLI tools like sql-formatter or pgFormatter.

Why This Matters

Clean SQL isn't just about aesthetics. It's about:

Code review speed — reviewers can spot issues faster
Debugging — you can isolate problems when each clause is on its own line
Onboarding — new team members can read your queries without a Rosetta Stone
Version control — clean diffs when each element has its own line

SQL formatting is one of those small investments that pays off every single day. Start with rule #1 (one clause per line) and build from there.

What formatting conventions does your team follow? Drop a comment — I'm always looking to improve my SQL game.