Formatador SQL

Antes e depois

Antes:

SELECT u.id,u.name,COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at>='2024-01-01' GROUP BY u.id,u.name HAVING COUNT(o.id)>5 ORDER BY orders DESC LIMIT 50;

Depois (vírgula inicial, palavras-chave em maiúsculas, indentação de 2 espaços):

SELECT
    u.id
  , u.name
  , COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.id
WHERE u.created_at >= '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY orders DESC
LIMIT 50;

Escolhas de estilo que importam

• Palavras-chave em maiúsculas vs minúsculas. MAIÚSCULAS é tradicional e escaneável. Minúsculas são mais limpas em editores de código modernos com destaque de sintaxe.
• Vírgulas iniciais vs finais. Inicial ( , col) facilita comentar uma única coluna. Final (col,) é mais natural na leitura do texto.
• Colocação de vírgula em GROUP BY. Frequentemente uma por linha para cláusulas longas, inline para curtas.
• Indentação de JOIN. ON na próxima linha (indentação suspensa) vs na mesma linha. Condições longas se beneficiam da indentação suspensa.
• Subconsultas. Indente toda a subconsulta, não apenas o parêntese de abertura.

Armadilhas específicas do dialeto

• Backticks do MySQL vs aspas duplas do PostgreSQL para identificadores.
• CTEs WITH, MS SQL tem um requisito de ; antes de WITH; o formatador lida com isso.
• Funções de janela, cláusulas longas OVER (...) se beneficiam de PARTITION BY e ORDER BY quebrados em linha.
• BigQuery tem ARRAY_AGG, STRUCT e sufixos de tabela (*_yyyymmdd) que o tokenizador não deve quebrar.
• Oracle tem a sintaxe de junção externa (+), o formatador a preserva, mas a sinaliza como legado.

O que o formatador não faz

• Corrigir bugs, um JOIN inválido permanece inválido.
• Expandir SELECT *, listas de colunas não são inferidas a partir do esquema.
• Otimizar consultas, apenas layout, não planos de execução.
• Reescrever subconsultas como CTEs, uma preocupação diferente.