Formatador de SQL | Separe Consultas Compactas em Cláusulas Legíveis

Cole um despejo SQL de uma linha só vindo de um log de ORM ou de uma consulta minificada, e esta ferramenta o divide em linhas separadas por cláusula — SELECT, FROM, WHERE, JOIN — com indentação de 4 espaços. As palavras reservadas são normalizadas para maiúsculas, e mais de 100 palavras-chave, literais de texto, números e comentários ganham destaque colorido.

💡 Sobre esta ferramenta

Você abre um pull request e o SQL ali é uma única linha longa. Não dá para ver onde termina a condição de junção e onde começa o filtro. Esta ferramenta traça essas fronteiras de cláusula de forma mecânica para que a consulta fique legível de relance.

A formatação se apoia em um analisador léxico, não em uma expressão regular ingênua. Os literais de texto ('...' e "...") e os comentários (-- de linha e /* */ de bloco) são extraídos como tokens distintos, então o conteúdo deles nunca é alterado: só as palavras-chave fora deles passam a maiúsculas. Cláusulas compostas como GROUP BY, ORDER BY e LEFT OUTER JOIN são reconhecidas como uma unidade e colocadas em sua própria linha. Quando uma subconsulta abre com SELECT entre parênteses, a indentação aumenta um nível e recua no parêntese de fechamento, de modo que a profundidade de aninhamento aparece direto no recuo. As expressões CASE indentam seus ramos WHEN / THEN / ELSE e se alinham em END.

Os painéis de entrada e saída ficam lado a lado, então você pode comparar o original com o resultado. Copie a saída direto para um cliente SQL ou um comentário de revisão de código.

🧐 Perguntas frequentes

P. Quais dialetos de SQL são suportados? R. Além do SQL padrão, o conjunto de palavras-chave cobre identificadores com crase do MySQL, RETURNING / ON CONFLICT do PostgreSQL e termos de funções de janela como OVER / PARTITION BY: mais de 100 palavras reservadas comuns aos principais dialetos. Funções próprias de cada dialeto são tratadas como identificadores, o que não afeta o layout.

P. Um SELECT dentro de uma string será colocado em maiúsculas? R. Não. Os literais de texto entre aspas simples ou duplas e os comentários são isolados como tokens separados durante a análise, e o conteúdo deles é mantido como está.

P. Posso formatar várias instruções de uma vez? R. Sim. Instruções separadas por ponto e vírgula (;) são formatadas individualmente, com uma linha em branco inserida entre elas.

P. Posso mudar a largura da indentação? R. Ela é fixa em 4 espaços. Ajuste depois com a função localizar e substituir do seu editor caso prefira o estilo de 2 espaços.

P. O resultado pode sair errado em algum caso? R. SQL montado por concatenação de strings ou salpicado de marcadores de template (como {{ }}) foge da gramática que o analisador espera, então as quebras de linha podem cair em lugares inesperados.

📚 Curiosidades

O hábito de escrever as palavras-chave de SQL em maiúsculas remonta a uma época em que o SQL foi projetado para ignorar maiúsculas e minúsculas, e destacar as palavras reservadas em caixa alta era um jeito prático de separá-las dos identificadores num terminal monocromático. O SQL ANSI aceita palavras-chave em minúsculas sem problema, mas muitos guias de estilo ainda recomendam maiúsculas por tradição. O tratamento de maiúsculas nos identificadores, por outro lado, varia por banco: o PostgreSQL converte para minúsculas os identificadores sem aspas. Um formatador que coloca em maiúsculas apenas as palavras reservadas e preserva a grafia original dos identificadores evita quebrar essas diferenças.