Formatador de SQL

Um formatador que coloca palavras-chave em maiúsculas comparando palavras inteiras com uma expressão regular não tem como saber se uma dada ocorrência de "order" é a palavra-chave SQL `ORDER` (como em `ORDER BY`) ou um valor de string literal que por acaso contém essa palavra — uma consulta filtrando linhas `WHERE description = 'the order from stock'` tem a palavra "order" dentro de uma string entre aspas, não funcionando de jeito nenhum como palavra-chave. Um formatador ingênuo coloca em maiúsculas cada palavra correspondente não importa o contexto, corrompendo o valor de string literal para `'the ORDER FROM stock'` e mudando silenciosamente o que a consulta realmente filtra. Tokenizar corretamente a consulta — reconhecendo os limites de strings entre aspas antes de decidir o que conta como palavra-chave — é o que previne isso, e é precisamente a classe de erro que só aparece com dados reais contendo palavras que por acaso coincidem com palavras-chave SQL, por isso é fácil de passar despercebido ao testar com consultas de exemplo simples.

Esta ferramenta reconhece a estrutura de cláusulas comum compartilhada entre PostgreSQL, MySQL, SQL Server, SQLite e Oracle — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY e seus parentes — bem o bastante para indentar cada cláusula em sua própria linha e aninhar corretamente subconsultas. Ela não constrói um entendimento completo da gramática completa de nenhum banco de dados específico, incluindo extensões específicas de fornecedor como a sintaxe de array do PostgreSQL ou a colocação da cláusula `TOP` do SQL Server. A consequência prática é que sintaxe específica de dialeto passa através do formatador intocada em vez de causar um erro, mas também não vai receber a mesma indentação cuidadosa que as cláusulas comuns recebem — uma troca razoável por suportar cinco dialetos com um único formatador em vez de precisar de uma ferramenta separada por motor de banco de dados.

Palavras-chave SQL não diferenciam maiúsculas de minúsculas pela própria especificação da linguagem — `SELECT`, `Select` e `select` são idênticas para qualquer motor SQL — o que é precisamente o que torna colocá-las em maiúsculas ou minúsculas uma operação puramente cosmética sem nenhum risco de alterar o comportamento. O mesmo se aplica aos espaços em branco e quebras de linha que este formatador adiciona: uma consulta espalhada por doze linhas indentadas roda identicamente à mesma consulta amontoada em uma. Nada da formatação toca os tokens reais que determinam quais tabelas são lidas, quais condições filtram linhas, ou quais valores são inseridos — apenas como essa mesma consulta lógica é disposta visualmente para um humano que a lê depois.

Uma consulta gerada por um ORM, exportada de uma interface gráfica de banco de dados, ou escrita como uma única linha extensa durante uma migração apressada geralmente é funcionalmente correta mas genuinamente difícil de revisar para uma pessoa exatamente como está escrita — uma consulta com quinze joins sem quebras de linha dificulta ver quais condições pertencem a qual join, ou se uma cláusula WHERE está filtrando a tabela correta. Reformatá-la com cada cláusula e cada join em sua própria linha, indentado para refletir a estrutura real da consulta, geralmente é a forma mais rápida de realmente entender o que uma consulta longa gerada faz antes de aprová-la em uma revisão de código ou depurar por que retorna as linhas erradas.