Gerador de EditorConfig

O que o .editorconfig faz

Um arquivo chamado .editorconfig na raiz de um projeto declara convenções de formatação. Editores com suporte a EditorConfig (todas as IDEs principais e a maioria dos editores de texto modernos) aplicam essas regras quando um arquivo é aberto. A busca sobe pela árvore de diretórios a partir do arquivo em edição e para no primeiro arquivo que diz root = true.

Exemplo de saída

Com as configurações padrão (espaços, tamanho de indentação 4, LF, utf-8) e as duas seções já marcadas para você, o gerador produz:

root = true

[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
max_line_length = 120

[*.{md,markdown}]
trim_trailing_whitespace = false

[{Makefile,makefile,GNUmakefile,*.mk}]
indent_style = tab

Marque Python, Go ou YAML e a seção correspondente aparece abaixo, já com a convenção que o formatador daquele ecossistema impõe.

Diretivas principais

Três regras que quebram o build, não apenas o guia de estilo

A maioria das entradas de um .editorconfig é preferência. Estas três não são, e são elas que justificam ter uma seção por linguagem:

• O YAML proíbe o caractere de tab na indentação. É um erro de parsing, não um aviso de linter. Se o seu projeto indenta com tabs e você tem workflows do GitHub Actions, arquivos do Docker Compose ou manifestos do Kubernetes, a seção YAML precisa forçar os espaços de volta.
• O make exige um tab literal no início de cada linha de receita. Um espaço produz missing separator. Stop. e o build para. É por isso que [{Makefile,makefile,GNUmakefile,*.mk}] lista várias grafias: o EditorConfig compara nomes de arquivo diferenciando maiúsculas de minúsculas, e existem repositórios com Makefile e com makefile.
• Um script de shell salvo com CRLF não roda. O kernel lê o retorno de carro como parte do caminho do interpretador e informa algo como /bin/bash^M: bad interpreter: No such file or directory. Os arquivos batch do Windows têm o problema espelhado: o cmd.exe localiza goto e call :label por deslocamento de bytes, então um .bat salvo apenas com LF pode pular para a linha errada ou parar no meio do caminho sem erro nenhum.

Duas dessas podem ser causadas pelo bloco global em vez de resolvidas por ele, e é por isso que este gerador fica de olho nelas. Se você escolher tabs e não adicionar a seção YAML, ou escolher CRLF e não adicionar a seção de shell, o arquivo gerado vai quebrar esses arquivos mesmo sem nunca citá-los. O gerador avisa isso acima da saída em vez de deixar você descobrir por um pipeline quebrado. O mesmo vale para os charsets utf-16: eles valem para todos os arquivos do projeto, e o make, os interpretadores de shell e o Python não conseguem ler código salvo assim.

Convenções de linguagem que este gerador escreve

Repare no que não está nessa tabela: o comprimento de linha. A PEP 8 diz 79, o Black diz 88, a PSR-12 fala em 120 como limite flexível e o rustfmt usa 100. Escrever qualquer um desses números numa seção de linguagem sobrescreveria em silêncio o limite que você escolheu para o projeto inteiro, então o gerador mantém max_line_length apenas no bloco [*] e guarda esses números aqui, onde você pode aplicá-los de propósito.

O seu editor tem suporte?

Suporte nativo: VS Code, a família IntelliJ da JetBrains, Visual Studio, Sublime Text, Xcode e Notepad++. Vim, Emacs, Neovim e alguns outros precisam de um plugin pequeno. O arquivo é INI puro, então linters e formatadores também conseguem lê-lo, e é assim que o Prettier e alguns language servers se mantêm alinhados com ele.