Opção Quantidade máxima de colunas

Quantidade máxima de colunas é o comprimento da linha mais longa que o formatador deixa na saída. Esta página explica exatamente como as linhas longas são quebradas, o que a opção deliberadamente não faz e como escolher uma largura, inclusive 0 para desligar a quebra.

O que a opção faz

A formatação acontece em duas etapas. Primeiro a consulta é montada: uma cláusula por linha, um item do select por linha, joins e condições em linhas próprias, subconsultas indentadas. Depois, numa passada final, cada linha da saída é medida. Uma linha que cabe no limite fica como está. Uma linha mais longa é cortada no último espaço que mantém a primeira parte dentro do limite, e o restante continua numa nova linha, indentada 2 espaços a mais do que a linha de onde veio. Se a continuação ainda ficar longa demais, o mesmo corte é repetido nela.

Na prática, as linhas longas são quase sempre itens calculados do select e condições do WHERE com expressões longas. Consultas curtas não são afetadas.

Valores possíveis e padrão

A mesma consulta em várias larguras

A consulta abaixo tem uma coluna calculada longa e uma condição longa. Com o padrão de 120, só o item do select passa do limite (131 caracteres), então apenas o seu alias vai para uma linha de continuação. Com 60, tanto a expressão quanto a condição são quebradas.

select order_id, base_amount + freight_amount + insurance_amount + handling_fee - store_credit - gift_card_amount - promo_discount as amount_due from order_lines where base_amount + freight_amount + insurance_amount > minimum_order_value + regional_surcharge

SELECT order_id,
    base_amount + freight_amount + insurance_amount + handling_fee - store_credit - gift_card_amount - promo_discount
      AS amount_due
FROM order_lines
WHERE base_amount + freight_amount + insurance_amount > minimum_order_value + regional_surcharge

SELECT order_id,
    base_amount + freight_amount + insurance_amount +
      handling_fee - store_credit - gift_card_amount -
      promo_discount AS amount_due
FROM order_lines
WHERE base_amount + freight_amount + insurance_amount >
  minimum_order_value + regional_surcharge

Com 40, a mesma regra simplesmente é aplicada mais vezes. Repare que cada linha de continuação fica exatamente 2 espaços mais para dentro do que a sua primeira linha: 6 espaços para o item do select, que começa em 4, e 2 espaços para a condição, que começa na coluna 0.

SELECT order_id,
    base_amount + freight_amount +
      insurance_amount + handling_fee -
      store_credit - gift_card_amount -
      promo_discount AS amount_due
FROM order_lines
WHERE base_amount + freight_amount +
  insurance_amount >
  minimum_order_value +
  regional_surcharge

Com 0, nada é quebrado. O item do select fica numa única linha de 131 caracteres e a condição numa linha de 96 caracteres:

SELECT order_id,
    base_amount + freight_amount + insurance_amount + handling_fee - store_credit - gift_card_amount - promo_discount AS amount_due
FROM order_lines
WHERE base_amount + freight_amount + insurance_amount > minimum_order_value + regional_surcharge

O que ela não faz

Como a quebra é uma passada final sobre o texto e não faz parte do layout, vale a pena saber algumas coisas:

• Ela não remonta as cláusulas. Um limite largo nunca junta os itens do select de volta numa linha só, e um limite estreito nunca move uma condição ou um join inteiro para outro lugar. A estrutura das cláusulas é idêntica em qualquer largura; compare as saídas com 0 e com 120 acima.
• Ela não procura um ponto de quebra lógico. O corte acontece no último espaço que cabe, o que pode cair entre um operador e o seu operando ou entre o AS e o alias, como mostra o exemplo com 120. Ela não dá preferência a quebrar antes de um + ou depois de uma vírgula. Quando o último espaço que cabe vem logo depois de uma vírgula, a vírgula fica no fim da primeira linha, como em NUMERIC(18, seguido de 4) na linha de continuação.
• Ela nunca corta dentro de texto entre aspas ou de comentários. Literais de string, identificadores entre aspas e comentários -- ou /* */ são mantidos inteiros, e o texto de um comentário nunca vai parar numa linha em que seria lido como SQL. Uma linha que é longa só por causa de um literal ou de um comentário longo pode continuar acima do limite.
• Ela nunca divide uma palavra. Um identificador mais longo do que o limite vai para uma linha só dele e fica acima do limite.
• Ela não junta linhas. Aumentar o limite nunca une linhas que o layout mantém separadas.

Por isso, trate a opção como uma rede de segurança que mantém as linhas dentro da sua tela ou da sua ferramenta de revisão, e não como uma forma de desenhar o formato de uma consulta. Se uma expressão é quebrada três vezes na largura escolhida, a correção legível normalmente está no próprio SQL: leve o cálculo para uma CTE ou para uma coluna derivada com um alias claro, como mostrado em formatação de consultas complexas.

Escolhendo uma largura

• 120 (padrão). Cabe numa janela de editor típica com a barra lateral aberta e coincide com o limite de linha que muitos times já usam no código da aplicação. A maioria das consultas bem estruturadas nunca chega a ele.
• 80 a 100. Útil quando o SQL é revisado em diffs lado a lado, lido num terminal ou colado em documentação e em tickets com largura fixa. Espere mais expressões quebradas.
• Abaixo de 60. Raramente ajuda. Linhas muito indentadas ficam com pouquíssimo espaço, a saída vira uma coluna de fragmentos e, em larguras muito pequenas, algumas linhas simplesmente não podem ser cortadas o suficiente e continuam acima do limite.
• 0. Use quando a saída não puder conter nenhuma quebra de linha que o layout não tenha criado, por exemplo ao comparar consultas formatadas numa ferramenta que já faz a quebra visual por conta própria, ou quando o SQL gerado é armazenado e comparado por uma máquina, e não lido por pessoas.

Lembre-se de que a indentação conta na largura. Com espaços de indentação em 4, uma linha dentro de uma subconsulta com dois níveis de profundidade já começa na coluna 8, então é quebrada antes do que o mesmo texto no nível superior. Reduzir a indentação para 2 costuma resolver melhor as consultas muito aninhadas do que aumentar o limite.

Dicas para revisão de código

A largura escolhida afeta os diffs tanto quanto a legibilidade. Linhas quebradas se deslocam quando um identificador muda de tamanho: renomear uma coluna pode mudar o ponto de corte e alterar também a linha de continuação. Se o seu time revisa SQL em pull requests, escolha uma largura uma única vez, registre-a junto com as suas outras convenções de revisão de código e mantenha os cálculos longos curtos o bastante para que nem sejam quebrados. As outras opções, posição das vírgulas e caixa das palavras-chave, não mudam o comprimento das linhas de um jeito que importe aqui.