Espaços versus guias: ergonomia do desenvolvedor e realidade do conjunto de ferramentas
Como tomar uma decisão de estilo que mantenha o código legível, inclusivo e fácil de automação
O debate ainda está vivo
Toda chamada de onboarding ainda tem aquele momento: alguém pergunta se a equipe prefere espaços ou abas e a sala fica em silêncio. O debate já não é ideológico; as ferramentas que enviamos determinam o quão acessível é o nosso código, quão limpas são as nossas diferenças e quão previsíveis se tornam as nossas migrações automatizadas.
O objetivo deste guia é simples: fornecer uma estrutura repetível que você possa colar em seu manual de engenharia para que a questão "espaços versus tabulações" pare de custar tempo de sprint.
Critérios-chave que devem orientar a decisão
- Requisitos de acessibilidade – Leitores de tela e fontes monoespaçadas se comportam de maneira diferente com paradas de tabulação.
- Estabilidade de diferenças – Os bots e revisores de CI preferem a formatação determinística para evitar PRs barulhentos.
- Padrões do ecossistema de idiomas - Os conjuntos de ferramentas Go, Python e Rust são fornecidos com opiniões incorporadas.
- Pegada herdada - Você pode ter dezenas de milhares de linhas já formatadas de uma maneira.
- Suporte ao editor – Os desenvolvedores ainda alternam entre VS Code, JetBrains e Vim no mesmo repositório.
Qual é o padrão dos fornecedores do conjunto de ferramentas
| Linguagem / Ecossistema | Formatador Oficial | Recuo padrão | Substituir opções |
|---|---|---|---|
| JavaScript / TypeScript | Mais bonito | 2 espaços | tabWidth, useTabs |
| Pitão | Preto | 4 espaços | Nenhum (guias rejeitadas) |
| Ir | gofmt | Guias | Substituições raras via gofmt -tabs=false |
| Ferrugem | ferrugem | 4 espaços | Configuração instável necessária |
| C# | formato dotnet | 4 espaços | .editorconfig |
Se você se alinhar aos padrões do ecossistema, receberá atualizações gratuitas sempre que o formatador adicionar uma regra. Lutar contra os padrões significa manter configurações personalizadas para sempre.
Considerações sobre acessibilidade e leitor de tela
- As guias são renderizadas em larguras variáveis dependendo das configurações do usuário. Isso é ótimo para usuários avançados, mas confuso para leitores de tela que esperam espaçamento uniforme.
- Os espaços fornecem layout determinístico para telas Braille e síntese de fala porque cada espaço é anunciado de forma consistente.
- Para equipes com habilidades mistas, a escolha mais segura são espaços para recuo e tabulações reservadas para alinhamento em tabelas de dados onde a flexibilidade é importante.
Higiene Diff: Como os revisores vivenciam sua escolha
Considere um arquivo TypeScript onde um desenvolvedor adiciona duas cláusulas de guarda. Com guias configuradas em 4 espaços, um revisor usando um console Git de 80 colunas pode ver todo o realinhamento do diff. Os espaços mantêm a diferença localizada.
if (!user?.profile) {
return redirect('/login')
}
if (!user.isOnboarded) {
return redirect('/welcome')
}O trecho acima com espaços produz uma pequena diferença porque cada formatador concorda com o número exato de caracteres. As guias geralmente aumentam ou diminuem com base nas configurações do editor local, produzindo alterações "fantasmas" em linhas não relacionadas.
O padrão híbrido que funciona em 2025
Um compromisso prático adotado por muitas equipes de produto:
- Recuo: Use espaços (2 ou 4) aplicados pelo seu formatador.
- Alinhamento: permite guias apenas em Makefiles, código Go ou tabelas de dados onde o alinhamento é semanticamente significativo.
- Automação: Adicione
.editorconfigalém de scripts de formatador para que nenhum ser humano comprometa espaços em branco manualmente.
Exemplo .editorconfig
root = true
[*]
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true
[*.go]
indent_style = tab
indent_size = 4
[Makefile]
indent_style = tab
[*.md]
trim_trailing_whitespace = falseManual de migração para repositórios legados
- Escolha um formatador que entenda sua linguagem (Prettier, rustfmt, clang-format, etc.).
- Gere uma comparação de linha de base na ramificação principal e marque-a como
style-migration-basepara que futuras sessões de culpa tenham um ponto de verificação. - Execute o formatador uma vez em todo o repositório. Confirme com uma mensagem como
chore: normalize whitespace. - Ative a aplicação de CI usando um trabalho lint. Exemplo de ação do GitHub:
name: formatting
on: [pull_request]
jobs:
prettier:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm run lint:format- Documente a decisão em seu manual de engenharia para que novas contratações não ressuscitem o debate.
Quando as guias não são negociáveis
- Projetos Go -
gofmtguias de saída; combater isso significa manter um formatador bifurcado. - Makefiles - A sintaxe requer uma tabulação literal para linhas de receita; espaços geram erros de tempo de execução.
- Bases de código de kernel ou firmware onde o alinhamento com os documentos de hardware é importante.
Use substituições .editorconfig para que a exceção permaneça no nível do tipo de arquivo, em vez de no conhecimento tribal.
Matriz de decisão para sua equipe
| Restrição | Escolha espaços se... | Escolha guias se... |
|---|---|---|
| Monorepo de idioma misto | Maioria favorece espaços | A maioria é Go / Make |
| Colaboradores em leitores de tela | Acessibilidade é prioridade | A equipe pode garantir ferramentas fáceis de usar |
| Formatação de CI | O padrão do formatador é espaços | Guias de saída do formatador |
| Estabilidade do histórico do Git | Você quer linhas de culpa consistentes | As diferenças de largura das guias são aceitáveis |
Lista de verificação de implementação
- [] Combine o tamanho do recuo (2 vs 4) por escrito.
- [] Confirme
.editorconfige formate os scripts. - [] Adicione um protetor de CI que falha no desvio de espaço em branco.
- [] Documente exceções (Go, Makefile) diretamente no repositório README.
- [] Execute uma migração única e marque o commit.
TL; DR para seu manual
Os espaços oferecem previsibilidade, acessibilidade e diferenças limpas. As guias continuam essenciais em alguns ecossistemas. A política mais sustentável é seguir os padrões do formatador, codificar a decisão em automação e nunca mais confiar nas configurações individuais do editor.
Antes de sua próxima retrospectiva, copie este artigo em seu wiki interno e torne a decisão explícita. A guerra de chamas termina quando o trabalho de fiapos é executado.