Raw SQL from ORMs, query logs, or copy-pasted examples often looks like a wall of text. Unreadable queries slow down code reviews, hide bugs, and make onboarding painful. Formatting your SQL is one of the highest-ROI habits a developer can build — and the Dev Cosmos SQL Formatter does the heavy lifting instantly.
Why SQL Formatting Matters
Consider this query pulled from a production log:
-- Before formatting
select u.id,u.first_name,u.last_name,u.email,count(o.id) as order_count,sum(o.total) as total_spent from users u left join orders o on u.id=o.user_id where u.is_active=1 and u.created_at>='2024-01-01' group by u.id order by total_spent desc limit 50
And after running through the formatter:
-- After formatting
SELECT
u.id,
u.first_name,
u.last_name,
u.email,
COUNT(o.id) AS order_count,
SUM(o.total) AS total_spent
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE
u.is_active = 1
AND u.created_at >= '2024-01-01'
GROUP BY u.id
ORDER BY total_spent DESC
LIMIT 50
The logic is identical. The second version takes seconds to parse mentally; the first can take minutes.
Formatter Options Explained
Keyword Casing
The SQL standard doesn't mandate case for keywords, but every team should pick one and stick to it:
| Mode | Example | Best For |
|---|---|---|
| UPPERCASE | SELECT FROM WHERE | Most common, maximum keyword visibility |
| lowercase | select from where | Preferred by some PostgreSQL teams |
| TitleCase | Select From Where | Rare — avoid for consistency reasons |
Indentation
The formatter supports 2 spaces, 4 spaces, or tabs. Four spaces is the most common SQL convention and produces alignment that's easy to follow. Tabs work well if your team uses them for all code.
Dialect
Different databases have slightly different syntax. The formatter respects dialect-specific keywords:
- Standard SQL — ANSI SQL, safe for any database
- PostgreSQL — Includes
ILIKE,RETURNING,NULLS FIRST/LAST - MySQL — Handles backtick identifiers,
LIMIT x, ysyntax - SQL Server — Recognises
TOP,NOLOCK, T-SQL keywords
A Practical SQL Style Guide
One Major Clause Per Line
Always start SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, and HAVING on their own lines at zero indentation. This creates a visual scaffold that makes the query structure immediately obvious.
Indent AND / OR
Place each condition on its own line, indented once, with AND/OR at the start of the line:
WHERE
status = 'active'
AND created_at >= '2024-01-01'
AND (role = 'admin' OR role = 'manager')
Use Meaningful Aliases
Single-letter aliases like u for users are fine in short queries but become confusing in complex ones with many joins. Consider full aliases: users AS usr, orders AS ord.
Prefer CTEs Over Nested Subqueries
Complex logic nested in subqueries is notoriously hard to read. Common Table Expressions (CTEs) with WITH give each logical step a name:
-- Hard to read: nested subquery
SELECT * FROM (
SELECT user_id, SUM(total) AS revenue
FROM orders
GROUP BY user_id
) ranked WHERE revenue > 1000;
-- Better: named CTE
WITH user_revenue AS (
SELECT user_id, SUM(total) AS revenue
FROM orders
GROUP BY user_id
)
SELECT * FROM user_revenue
WHERE revenue > 1000;
Common SQL Formatting Mistakes
| Mistake | Problem | Fix |
|---|---|---|
SELECT * | Fetches unused columns, breaks when schema changes | Always name columns explicitly |
| Mixed case keywords | SELECT from WHERE → confusing to scan | Pick one case, use it everywhere |
| No aliases on aggregates | COUNT(id) unnamed → unclear column name | Always use AS count_name |
| Inline comments in prod queries | Some drivers strip or choke on comments | Use comments in dev, strip for prod |
SELECT * breaks code silently when columns are added, reordered, or renamed. Always enumerate the columns you need.Formatting Workflow
- Write or paste the query into the Dev Cosmos SQL Formatter
- Choose your team's keyword casing and indent size
- Select the correct dialect for your database
- Click Format or press
Ctrl+Enter - Copy the formatted result back into your codebase