Guia de estilo SQL: boas práticas de formatação

Um guia de estilo SQL é um conjunto de convenções que tornam as consultas legíveis e mantêm os diffs de uma equipe consistentes. O SQL em si não se importa: palavras-chave não diferenciam maiúsculas de minúsculas e o espaço em branco é ignorado, então SELECT, select e SeLeCt rodam exatamente igual, e um one-liner de 200 caracteres devolve as mesmíssimas linhas que a mesma consulta espalhada por vinte linhas indentadas. O estilo, portanto, existe só para os humanos que vão ler a consulta depois.

Se você só precisa de uma consulta limpa agora, cole-a no Formatador SQL, escolha o dialeto e copie o resultado. Mas entender as regras por trás dessa saída é o que permite definir um padrão de equipe em vez de discuti-lo a cada pull request. Este guia percorre as escolhas que importam: maiúsculas e minúsculas em palavras-chave, indentação e quebras de linha, nomenclatura, peculiaridades de cada dialeto e como automatizar tudo isso.

Vale fixar uma ideia antes dos detalhes. Como o SQL ignora espaço em branco e capitalização, nenhuma dessas regras é imposta pelo banco de dados; elas existem para servir os humanos que leem, revisam e mantêm a consulta. Daí duas consequências. Primeiro, raramente existe uma única resposta “correta”: a maioria dessas decisões é escolher uma convenção razoável e aplicá-la em todo lugar, e este guia procura ser honesto sobre onde estão os compromissos reais, sem fingir que um estilo vence de forma absoluta. Segundo, como as regras são convenções e não exigências, elas só entregam valor quando você as aplica com consistência. Por isso cada seção acaba na mesma conclusão: decida uma vez e deixe uma ferramenta impor.

Por que a formatação de SQL importa

O argumento mais claro a favor da formatação aparece na revisão de código. Um ORM ou uma etapa de build muitas vezes emite consultas como uma única linha ininterrupta:

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.active=true group by u.id,u.name order by orders desc

Ninguém consegue revisar isso. Reformatada, a estrutura fica óbvia e o diff pode ser revisado linha a linha:

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.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

A depuração se beneficia da mesma forma. Quando você copia uma consulta de uma linha de um log de consultas lentas e ela tem três joins e um WHERE emaranhado, formatá-la primeiro transforma “onde está o bug” em uma varredura de trinta segundos. O predicado defeituoso fica na própria linha, os joins ficam empilhados, e um produto cartesiano acidental ou um filtro esquecido de repente se torna visível em vez de ficar enterrado num paredão de texto. O mesmo truque ajuda quando você está lendo SQL que algum outro sistema gerou: construtores de consultas e ferramentas de relatório costumam emitir saída correta, porém ilegível.

A consistência é o ganho mais discreto e, com o tempo, o mais valioso. Quando todos formatam do mesmo jeito, os diffs mostram só o que de fato mudou (uma coluna nova, um filtro ajustado) sem o ruído da preferência de espaçamento de uma pessoa brigando com a de outra. A atenção de quem revisa é finita; gastá-la com espaço em branco rearranjado é desperdício. A formatação consistente também facilita o onboarding: quem chega lê consultas parecidas entre si, aprende o formato da equipe uma vez e o aplica em todo lugar. Nada disso exige formatar à mão, que é o tema da seção final. Você decide as regras, uma ferramenta as aplica.

Um invariante sustenta tudo isso, e vale enunciá-lo com clareza porque se repete ao longo deste guia: a formatação só altera espaço em branco, quebras de linha, capitalização de palavras-chave e comentários. Ela nunca altera a lógica da consulta nem os seus resultados. Uma consulta formatada é a mesma consulta. É por isso que você pode rodar a versão bagunçada acima pelo Formatador SQL sem se preocupar com o que ela retorna.

Capitalização de palavras-chave: MAIÚSCULAS vs minúsculas

O debate mais antigo de qualquer guia de estilo SQL é se as palavras-chave reservadas devem ficar em MAIÚSCULAS ou minúsculas. Ambas são válidas, porque o SQL não diferencia maiúsculas de minúsculas em palavras-chave. A discordância é sobre legibilidade, e vale entender os dois lados antes de escolher.

A favor de palavras-chave em MAIÚSCULAS

O argumento tradicional é o contraste visual. Escrever SELECT, FROM, WHERE, JOIN e GROUP BY em maiúsculas faz as palavras-chave saltarem dos nomes de tabelas e colunas em minúsculas, então você consegue varrer o formato de uma consulta, suas cláusulas e sua estrutura, sem depender de um editor para colori-las.

Isso importa mais do que parece, porque o SQL passa por muitos lugares sem realce de sintaxe: arquivos de log, threads de e-mail, descrições de pull request, um diff em texto puro, uma mensagem no Slack, um painel de monitoramento, um stack trace. Em todos esses, as palavras-chave em maiúsculas são a única coisa que mantém a estrutura legível. Tire o realce e select id from users where active vira uma sopa de palavras minúsculas, enquanto SELECT id FROM users WHERE active ainda se lê como uma consulta de relance. Essa é a convenção da maioria dos guias de estilo mais antigos, da documentação de bancos de dados e de quase todo livro-texto de SQL, o que também explica por que muita gente acha as maiúsculas mais familiares mesmo quando o editor as coloriria de qualquer jeito.

A favor de palavras-chave em minúsculas

O contra-argumento moderno é que o realce de sintaxe resolveu o problema do contraste. Todo editor e IDE colore as palavras-chave de forma distinta, então capitalizá-las é redundante, e, para alguns leitores, o tudo-em-maiúsculas soa como gritaria. Também é um pouco mais rápido digitar sem alcançar o shift a cada palavra-chave.

O estilo minúsculo tem real impulso no mundo da engenharia de analytics. A comunidade dbt e vários guias de estilo de equipe bastante citados adotam palavras-chave em minúsculas por padrão, partindo da lógica de que o realce carrega o peso visual e as minúsculas deixam a consulta mais calma de ler. Há um ponto mais sutil a favor delas também: palavras-chave em minúsculas ficam no mesmo nível visual dos nomes de tabela e coluna em snake_case, então a consulta inteira se lê como um único bloco de texto consistente, e não como dois registros (palavras-chave gritando, identificadores quietos) disputando atenção. Se isso é qualidade ou defeito é exatamente o tipo de coisa em que as equipes discordam, o que nos leva ao único veredito que de fato se sustenta.

O veredito: a consistência vence a escolha

Aqui está a parte que de fato importa: qual delas você escolhe é muito menos importante do que escolher uma e impô-la. Uma base de código onde metade das consultas grita SELECT e a outra metade sussurra select é o pior resultado, porque a própria inconsistência vira ruído. Capitalização misturada numa única consulta é pior ainda.

A razão de a consistência vencer é mecânica, não estética. Capitalização inconsistente faz os diffs mentirem: quem revisa vê uma “mudança” de linha que na verdade é só alguém reformatando uma palavra-chave, e a mudança real se esconde no ruído. O grep e a busca também ficam menos confiáveis quando a mesma palavra-chave aparece em três capitalizações. Um único estilo imposto remove tudo isso ao custo de uma decisão. Então decida em equipe, registre por escrito e deixe uma ferramenta impor, em vez de confiar na disciplina. O Formatador SQL tem um controle de Palavras-chave com três opções (MAIÚSCULAS, minúsculas e Preservar) para que você normalize uma pilha inteira de consultas históricas para um só estilo num único clique. A mesma consulta, renderizada das duas formas:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Escolha a que sua equipe prefere. O importante é que todas as suas consultas sigam o padrão.

Indentação e quebras de linha

A capitalização decide como as palavras-chave parecem. A indentação e as quebras de linha decidem como a lógica da consulta se mapeia na página, e é aqui que mora a maior parte da legibilidade.

O estilo “rio” vs o estilo bloco

O conhecido sqlstyle.guide de Simon Holywell popularizou o estilo “rio”, em que as palavras-chave ficam alinhadas à direita de modo que um canal vertical de espaço em branco corre pelo meio da consulta:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

O atrativo é que SELECT, FROM e WHERE se alinham pela borda direita e a lista de colunas fica organizada à direita do rio. As desvantagens, porém, são práticas. O alinhamento depende do comprimento da sua palavra-chave mais longa, então adicionar um LEFT JOIN pode te obrigar a reindentar tudo; é trabalhoso de manter à mão; e produz diffs ruidosos, porque mudar o comprimento de uma palavra-chave desloca o espaço em branco das linhas vizinhas.

O estilo bloco (ou alinhado à esquerda) começa cada cláusula principal na margem esquerda, em sua própria linha, e indenta o conteúdo da cláusula:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

Esse é o padrão dominante e o que a maioria das ferramentas produz, justamente porque é estável: adicionar uma cláusula nunca rearranja as linhas acima, então os diffs ficam pequenos e o layout sobrevive à formatação automática. O estilo rio otimiza para como uma consulta finalizada parece isolada; o estilo bloco otimiza para como as consultas mudam ao longo do tempo e como são revisadas no controle de versão. Para qualquer coisa que viva em um repositório e seja editada, o estilo bloco é a aposta mais segura, e é o que o resto deste guia assume.

Quantos espaços: 2 vs 4 vs tabs

Depois de indentar, você precisa decidir o quanto. As três respostas comuns têm, cada uma, sua justificativa:

• 2 espaços: o padrão mais comum. Mantém os diffs compactos e impede que consultas aninhadas marchem para fora da borda direita da tela.
• 4 espaços: dão a cada nível de aninhamento mais separação visual, o que ajuda em consultas com subconsultas profundas ou muitos níveis de CTE.
• Tabs: deixam cada desenvolvedor escolher a própria largura de exibição sem alterar o arquivo.

Não há resposta universalmente correta aqui, e é exatamente por isso que o Formatador SQL expõe um controle de Indentação com as três opções (2 espaços, 4 espaços, Tab). Escolha uma e aplique em todo lugar.

Onde quebrar as linhas

A largura da indentação é a parte fácil. A decisão de maior impacto é onde inserir as quebras de linha:

• Colunas do SELECT: uma coluna por linha para qualquer coisa não trivial, de modo que adicionar ou remover uma coluna toque exatamente uma linha no diff. Consultas bem curtas podem ficar em uma única linha.
• FROM e JOIN: comece cada join em sua própria linha, com a condição ON ou no fim da linha ou indentada abaixo dela. Isso mantém o grafo de joins legível.
• WHERE: coloque cada AND / OR em sua própria linha para que a lógica booleana se leia de cima para baixo. Para condições mistas de AND/OR, coloque entre parênteses e indente os grupos para que a precedência fique explícita, e não algo que o leitor precise deduzir.

Estas são diretrizes, não leis. Um trivial SELECT id FROM users WHERE id = 1 não precisa de cinco linhas, e forçá-lo a elas prejudica a legibilidade em vez de ajudar. O critério é mais ou menos: quebre quando a consulta tiver mais de uma ou duas colunas, mais de uma tabela ou mais de uma condição. Abaixo desse limiar, uma única linha é mais clara; acima dele, quebre com vontade. Um bom formatador codifica um limiar sensato para você, mas vale entender o princípio para que a saída nunca te surpreenda.

Aplicadas ao one-liner bagunçado lá de cima, essas regras produzem um layout em que cada cláusula e cada join ficam visíveis de relance:

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.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Vírgulas no início vs no fim

Uma questão menor, mas persistente: onde fica a vírgula numa lista de colunas em múltiplas linhas?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Vírgulas no início têm uma vantagem genuína: adicionar ou remover uma coluna muda uma única linha, e uma vírgula faltante é fácil de notar porque a linha problemática se destaca. Vírgulas no fim se leem de forma mais natural e são bem mais comuns na prática. As duas servem: escolha uma e deixe o formatador aplicá-la para que ninguém precise pensar nisso de novo.

Convenções de nomenclatura para tabelas e colunas

A formatação rege o espaço em branco; a nomenclatura rege os próprios identificadores, e um guia de estilo fica incompleto sem ela.

O padrão de fato para identificadores SQL é o snake_case: tudo minúsculo, palavras separadas por sublinhados, como user_id, created_at e order_items. Ele ganhou esse status por um motivo concreto, não só por hábito: identificadores em snake_case nunca precisam de aspas e se comportam de forma consistente entre dialetos, enquanto o camelCase (comum em código de aplicação) colide com a forma como os bancos de dados dobram a capitalização, ao que chegaremos já já.

Vale ser explícito sobre por que isso difere do código de aplicação. Na maioria das linguagens de programação, o código ao redor controla os identificadores, e camelCase ou PascalCase é a norma. Os identificadores SQL são interpretados pelas próprias regras de dobra de capitalização do banco de dados, e são justamente essas regras que tornam os nomes com capitalização mista frágeis. O snake_case desvia do problema inteiro: não há capitalização a dobrar, não há motivo para usar aspas e nada que se comporte de forma diferente de um mecanismo para outro.

Mais algumas convenções que aparecem em quase todo guia de estilo SQL:

• Nomes de tabela no singular vs no plural é uma divisão genuína. users (plural, “a tabela guarda usuários”) e user (singular, “cada linha é um usuário”) têm seus defensores. Como na capitalização, a escolha importa menos do que aplicá-la de forma consistente a toda tabela.
• Evite palavras reservadas como identificadores. Nomear uma coluna order, user ou table obriga você a usar aspas em todo lugar e convida a erros confusos. Prefira order_id ou account.
• Mantenha a nomenclatura de chaves consistente. Uma chave primária chamada id e chaves estrangeiras nomeadas <tabela_referenciada>_id (como user_id) tornam os joins previsíveis e autoexplicativos.

Há uma armadilha clássica aqui, que morde as equipes que nomeiam colunas de banco do mesmo jeito que nomeiam variáveis de aplicação. No PostgreSQL, um identificador sem aspas é dobrado para minúsculas, então SELECT userId FROM t na verdade procura por uma coluna chamada userid. No instante em que você usa aspas — "userId" — o banco preserva a capitalização e trata "userId" e userid como duas colunas diferentes:

-- Creates a column whose real name is lowercase "userid"
CREATE TABLE t (userId integer);

-- Both of these work — the name was folded to lowercase
SELECT userId FROM t;
SELECT userid FROM t;

-- This fails: "column \"userId\" does not exist"
-- The quotes force an exact, case-sensitive match
SELECT "userId" FROM t;

Note que bancos de dados diferentes dobram a capitalização em direções diferentes: o Oracle dobra identificadores sem aspas para maiúsculas, vários outros para minúsculas. Então identificadores com aspas e capitalização mista nem sequer são portáteis. A saída limpa é evitar por completo identificadores com aspas e capitalização mista e ficar no snake_case, que contorna o problema inteiro e mantém seu esquema legível em todo dialeto.

Para uma comparação mais aprofundada entre camelCase, snake_case e kebab-case — incluindo quando cada um é a escolha certa em código e dados — veja o guia de convenções de nomenclatura.

Formatação entre dialetos SQL

Tudo até aqui é, em grande parte, agnóstico de dialeto: capitalização, indentação, quebras de linha e nomenclatura valem independentemente de qual banco de dados você usa. Mas “formate este SQL” bate numa parede no instante em que sua consulta usa sintaxe específica de um banco, porque um parser genérico que não reconhece aquela sintaxe vai estragá-la: ele pode dividir um token no lugar errado, interpretar mal um operador ou tratar um caractere de aspas como delimitador de string e engolir metade da consulta. É aqui que a formatação ciente do dialeto se paga, e é a razão de o formatador pedir que você escolha um banco primeiro em vez de adivinhar. As diferenças abaixo são as que você encontra com mais frequência em consultas do dia a dia.

Operação	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Concatenação de strings	|| ou CONCAT()	CONCAT()	+ ou CONCAT()	|| ou CONCAT()	||
Fallback de NULL	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Limitação de linhas	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Aspas de identificadores	aspas duplas ("…")	crases	colchetes ([…])	aspas duplas ("…")	aspas duplas ("…")

Concatenação de strings e tratamento de NULL

Duas das operações mais comuns do dia a dia são escritas de formas diferentes entre os dialetos.

Concatenação de strings:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

Fallbacks de NULL:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Um formatador configurado para o dialeto errado pode não entender ISNULL ou o operador || e acabar interpretando mal a consulta ao redor.

Limitação de linhas e uso de aspas em identificadores

Limitar as linhas de resultado é uma das partes mais divergentes da sintaxe entre dialetos:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

O uso de aspas em identificadores também se divide em três. Quando você precisa colocar um identificador entre aspas — geralmente para usar uma palavra reservada ou preservar a capitalização — o delimitador depende do banco de dados:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Um formatador que pense que as crases do MySQL são delimitadores de string, ou que os colchetes do T-SQL são outra coisa, vai produzir saída quebrada. A configuração de dialeto é o que diz qual é qual. É também por isso que copiar e colar uma consulta entre bancos raramente é uma troca limpa: a mesma intenção lógica — concatenar duas strings, recorrer a NULL, limitar a dez linhas, colocar uma palavra reservada entre aspas — é escrita de quatro formas diferentes entre os dialetos, e só o parser que conhece o seu banco consegue reformatá-la sem corrompê-la.

Por que a formatação ciente do dialeto importa

É exatamente por isso que o Formatador SQL vem com nove dialetos — PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB e Standard SQL — em vez de um único modo genérico. Selecionar o certo significa que o parser lida corretamente com strings entre cifrões e casts :: do PostgreSQL, identificadores entre colchetes e TOP do T-SQL, funções específicas de data warehouse no BigQuery e no Snowflake, e as regras de aspas acima, em vez de adivinhar e errar. Escolha o seu banco de dados real na lista suspensa antes de formatar, e a saída volta correta e idiomática.

Automatizando a formatação de SQL

Ler as regras é uma coisa; ninguém deveria aplicá-las à mão. A razão de existir de um guia de estilo é que uma máquina o imponha. Há três lugares onde encaixar a formatação, dependendo de quanto atrito você quer remover.

No seu editor (formatar ao salvar)

A opção de menor esforço é formatar automaticamente toda vez que você salva. O VS Code tem extensões de formatador SQL que rodam ao salvar, e o JetBrains DataGrip e as ferramentas de banco de outras IDEs já trazem um formatador embutido que você pode vincular a uma tecla ou a um hook de salvamento. Uma vez configurado, suas consultas simplesmente nunca ficam desformatadas, no mesmo modelo do Prettier para JavaScript ou do gofmt para Go. O porém é que as configurações do editor vivem na máquina de cada desenvolvedor, então formatar ao salvar mantém o seu SQL arrumado, mas não garante, por si só, que o do resto da equipe esteja. Para isso você precisa da próxima camada.

Na CI com um linter

Para impor o estilo em toda uma equipe, mova a verificação para a integração contínua. Um linter de SQL como o sqlfluff faz lint e também corrige automaticamente: você codifica suas regras — dialeto, capitalização de palavras-chave, indentação, posição das vírgulas — em um arquivo de configuração .sqlfluff, roda sqlfluff lint para sinalizar violações e sqlfluff fix para corrigi-las, e faz a CI reprovar qualquer pull request que se desvie do estilo combinado. É a mesma ideia do ESLint ou do Prettier barrando um repositório de frontend: o estilo deixa de ser um comentário de revisão que alguém precisa lembrar de deixar e vira uma verificação que passa ou falha, e que a máquina nunca esquece. O retorno é que os debates de estilo acontecem uma vez, quando você escreve a configuração, em vez de em cada pull request.

Formatação online pontual

Às vezes você tem só uma consulta feia e nenhuma vontade de instalar nada — um trecho de um log, a mensagem de um colega no Slack, uma consulta que você está colando na documentação. Para isso, cole-a no Formatador SQL, escolha o dialeto, a capitalização e a indentação, e copie o resultado limpo.

O detalhe da privacidade importa aqui, e é fácil passar batido. Muitos formatadores online enviam o texto que você cola para um servidor fazer o trabalho, ou seja, uma cópia da sua consulta (nomes de tabelas, nomes de colunas, às vezes valores literais de um incidente em produção) sai da sua máquina. O Formatador SQL roda inteiramente no seu navegador, então o seu SQL nunca é enviado para lugar nenhum. Isso o torna seguro para formatar consultas que tocam esquemas de produção ou lógica proprietária, que é justamente a situação em que você mais quer formatação limpa e menos quer entregar a sua consulta a terceiros. Se você lida com outros formatos no mesmo fluxo, o Formatador JSON irmão funciona do mesmo jeito: mesmo processamento no navegador, mesma cópia em um clique.

As três abordagens não são mutuamente exclusivas, e a melhor configuração costuma combiná-las: formatar ao salvar para o ciclo rápido enquanto você escreve, um linter na CI como rede de segurança que impõe o padrão da equipe, e um formatador online para os trechos descartáveis que nunca chegam ao seu repositório. Seja qual for a que você usar, vale repetir o invariante uma última vez: nenhuma dessas ferramentas muda o que a sua consulta faz. Elas rearranjam espaço em branco, quebras de linha, capitalização e comentários, e nada mais.

Perguntas frequentes

As palavras-chave SQL devem ficar em maiúsculas ou minúsculas?

Ambas são válidas, porque as palavras-chave SQL não diferenciam maiúsculas de minúsculas. MAIÚSCULAS fazem as palavras-chave se destacarem em ambientes sem realce de sintaxe, como logs e diffs; minúsculas são mais fáceis de digitar e combinam com editores modernos que já colorem as palavras-chave. O que de fato importa é que toda a equipe escolha uma e um formatador a imponha; capitalização misturada é a pior escolha.

Qual é a melhor indentação para SQL?

Dois espaços são o padrão mais comum e mantêm os diffs compactos; quatro espaços tornam consultas profundamente aninhadas mais fáceis de ler; tabs deixam cada desenvolvedor escolher a própria largura de exibição. Não há uma única resposta correta: escolha uma e aplique de forma consistente em toda a equipe. A maioria dos formatadores SQL, incluindo este, oferece as três opções.

Como formato SQL automaticamente?

Há três formas de formatar SQL automaticamente: formatar ao salvar no seu editor (VS Code ou DataGrip), um linter na CI como o sqlfluff que corrige o estilo automaticamente, ou um formatador SQL online para colagens pontuais. O caminho online é o mais rápido porque não precisa de instalação: é só colar, escolher o dialeto e copiar o resultado.

Devo usar vírgulas no início ou no fim das linhas em SQL?

Vírgulas no início (vírgula no começo de cada linha) dão diffs mais limpos ao adicionar ou remover colunas e tornam uma vírgula faltante fácil de notar; vírgulas no fim (vírgula no final) se leem de forma mais natural e são mais comuns. As duas são aceitáveis em qualquer guia de estilo SQL; a chave é escolher uma e deixar um formatador aplicá-la automaticamente.

Formatar SQL muda como a consulta roda?

Não. Formatar SQL só altera espaço em branco, quebras de linha, capitalização de palavras-chave e comentários; nunca altera a lógica da consulta. Uma consulta formatada retorna exatamente os mesmos resultados que a original, e é por isso que é completamente seguro embelezar até consultas de produção antes de revisá-las ou executá-las.

Qual convenção de nomenclatura devo usar para tabelas e colunas SQL?

O snake_case — tudo minúsculo com sublinhados — é o padrão de fato para nomes de tabelas e colunas SQL porque evita o uso de aspas e permanece seguro entre dialetos. Mantenha as chaves primárias (id) e as chaves estrangeiras (user_id) nomeadas de forma consistente, e evite usar palavras reservadas como order ou user como identificadores para prevenir dores de cabeça com aspas.

Como formato SQL para um dialeto específico, como PostgreSQL ou T-SQL?

Selecione o dialeto correspondente no formatador primeiro. O modo PostgreSQL lida corretamente com casts :: e strings entre cifrões; o modo SQL Server (T-SQL) entende [identificadores] entre colchetes e TOP. Escolher o dialeto errado deixa um parser genérico estragar a sintaxe específica do dialeto, então sempre o configure para o seu banco de dados real antes de formatar.

Existe um guia de estilo SQL padrão?

Não há um padrão oficial, mas existem vários bastante referenciados: o sqlstyle.guide de Simon Holywell e os guias de estilo públicos de equipes como a Mozilla e a comunidade dbt. O consenso compartilhado entre eles — indentação consistente, identificadores em snake_case e uma quebra de linha antes de cada cláusula principal — é o que este guia codifica, e um formatador pode impô-lo para você.