EditorConfig: padronização automática de estilo de código

Você prefere indentar seu código com 2 ou 4 espaços? Uma questão mais complexa: você usa espaço ou tab?! Se você e sua equipe ainda protagonizam discussões épicas sobre estilos de código, é hora de conhecer (e usar) o EditorConfig.

Continue lendo para saber o que é EditorConfig, como funciona EditorConfig, como usá-lo, porque usá-lo, conhecer todas as opções do EditorConfig e muito mais.

Para complementar os estudos, assista também ao nosso vídeo especial sobre o EditorConfig:

A importância da padronização de estilos de código

A maioria de nós, programadores/codificadores, temos apreço e apego ao código que fazemos. O mesmo acontece aos estilo de códigos que optamos por adotar.

São grandes as chances de, por exemplo, você já ter vivido (no mínimo, presenciado) algumas discussões acaloradas sobre as vantagens de se usar tabs ao invés de espaços (ou vice-versa).

Fato é que, preferências pessoais à parte, você pode participar de um projeto em que um coding style já esteja consolidado e, querendo ou não, gostando ou não, você vai ter que se adaptar às convenções de código usadas.

Entra em cena o EditorConfig.

O que é EditorConfig

E aí, naquelas horas que você adentra alegremente em uma nova equipe, com seus coding styles já consolidados, você vai passar por maus bocados para se adaptar a convenções que não está acostumado…

Não seria incrível se existisse uma maneira de otimizar a coisa toda? Uma maneira de seu código já ser escrito dentro do estilo adotado automaticamente?

Bem… Existe. :)

O nome dessa “maneira” é EditorConfig e ele ajuda a manter estilos de codificação consistentes entre desenvolvedores que trabalham no mesmo projeto, independentemente dos editores/IDEs usados por cada um.

Como funciona EditorConfig

EditorConfig consiste em um formato de arquivo para definir estilos de codificação e uma coleção de plugins de editores de texto e IDEs que permitem ler esse formato do arquivo para adequar o código aos estilos definidos.

Na prática, trata-se de um arquivo no projeto com instruções de estilo de codificação que, através de um plugin instalado, próprio ao editor/IDE usado, interpreta essas instruções e adapta automaticamente o código aos estilos definidos.

Por exemplo, se consta na definição dos estilos de código que a indentação usada será com espaços, você pode usar tabs à vontade que, assim que salvar o arquivo, todos serão convertidos automagicamente.

Os arquivos EditorConfig são facilmente legíveis (inclusive por humanos) e funcionam muitíssimo bem em qualquer opção para controle de versão (estamos falando de Git para 99% dos projetos de código).

Por que usar EditorConfig?

Se você pretende algum dia colocar o nome de grandes empresas em seu currículo, prepare seu espírito para codificar em estilos já determinados, já que grandes empresas possuem até manuais de codificação em que esses estilos de código devem ser seguidos à risca.

E não é à toa, já que padronizar a escrita do código (consequentemente, o estilo do código) é algo que realmente traz vantagens a qualquer projeto que pretenda ter um mínimo de qualidade e profissionalismo.

Padronização e consistência de código são características altamente desejáveis quando estamos falando de programação e codificação. Acredite, sem isso, as chances de um projeto escalar com qualidade são praticamente nulas.

E é por isso que usar EditorConfig deve ser seriamente considerado por você e sua equipe, já que ele traz uma automatização fantástica de estilo de código para qualquer projeto, seja quais forem as linguagens usadas.

EditorConfig vs Prettier vs ESLint

Uma dúvida comum é em relação a EditorConfig vs Prettier ou EditorConfig vs ESLint.

Eles não servem para a mesma coisa? Se o projeto já contar Prettier e/ou ESLint, é precisando também o EditorConfig?

A confusão é comum, mas a explicação é muito simples:

• ESLint. É um linter para JavaScript; analisa o código para ajudar a detectar problemas de formatação e encontrar inconsistências.
• Prettier. Semelhante ao ESLint, é um formatador de código.
• EditorConfig. Define uma espécie de guia de estilo de formatação de código padrão entre IDEs/editores usados na equipe.

Como usar o EditorConfig

EditorConfig consiste em um arquivo específico .editorconfig e um plugin que você deve instalar no seu editor de códigos ou IDE para que ele saiba como interpretar esse arquivo e faça as devidas conformidades no estilo dos códigos.

No site oficial você encontra a lista completa dos editores/IDEs que oferecem suporte ao EditorConfig, bem como os respectivos links para baixar os plugins.

Obviamente, há plugins para os editores mais populares; inclusive, para os menos populares, também. A ideia é que a facilidade de padronização de estilos de código esteja disponível amplamente.

Então, você vai poder usar EditorConfig no VSCode, EditorConfig no Visual Studio, Sublime Text, Brackets, Atom, Vim, Emacs, NetBeans, Eclipse, PhpStorm e muuuitos outros.

Para usar EditorConfig, basicamente você tem que instalar o devido plugin, criar um arquivo .editorconfig no projeto (caso já não exista) e… Pronto. Agora você também já vai contar com a facilidade de o EditorConfig autoformatar seus códigos para os acomodar aos estilos definidos!

Padrões do EditorConfig

As regras para a conformidade de coding style (que serão vistas abaixo) devem ser aplicadas no projeto, certo? Mas como saber quais arquivos serão afetados?

Para isso, é preciso definir quais padrões (tecnicamente, Wildcard Patterns) serão usados, sendo possível especificar curingas para caminhos e/ou tipos de arquivo diferentes.

A seguir, veja todos os padrões que o EditorConfig oferece para a padronização de estilo de código seja bastante flexível no projeto:

• *: corresponde a qualquer sequência de caracteres, exceto separadores de caminho (/)
• **: qualquer sequência de caracteres
• ?: qualquer caractere único
• [name]: qualquer caractere único em name
• [!name]: qualquer caractere único que não está em name
• {s1,s2,s3}: qualquer uma das strings fornecidas (separadas por vírgula)
• {num1..num2}: qualquer número inteiro entre num1 e num2, em que num1 e num2 podem ser positivos ou negativos

Lembrando que caracteres especiais podem ser escapados com barra invertida (\) para que não sejam interpretados como padrões curinga.

Então, com esses padrões/curingas à disposição, é possível especificar a aplicação das regras para qualquer parte da arquitetura do projeto ou arquivo(s) específico(s).

Por exemplo, suponha que seja preciso aplicar algumas regras de estilo de código a todos os arquivos JavaScript do projeto. O padrão usado seria:

Se fosse para todos os arquivos JavaScript e Python:

Em todos os arquivos dentro dos subdiretórios de src/assets:

Em um arquivo, em especial:

Todos os arquivos YAML e o específico package.json:

Enfim, deu para perceber que, usando qualquer um (ou qualquer combinação) dos padrões mostrados, é possível limitar/abranger qualquer(quaisquer) tipo(s) de arquivo(s) para receber os estilos de código.

Ah, e tem um que é bastante comum de se encontrar por aí, que serve para aplicar regras para absolutamente todos os artigos do projeto:

Bem facinho, hã?

Regras do EditorConfig

Agora que você já sabe como definir em quais partes do seu projeto você quer que as regras de estilos de código tenham efeito, chegou a hora de conhecer as regras, propriamente ditas.

Lembrando que as regras são case-insensitive, significando que é permitido escrever em minúsculo, maiúsculo, como você preferir.

Também, a ordem em que elas são escritas não influencia em nada, estando você livre para as dispor como julgar melhor: ordem alfabética, de “sentido”, “importância”, segundo o alinhamento de Marte com Saturno etc.

indent_style

Essa é a regra que põe fim à famosa guerra Tabs vs Spaces; define o tipo de indentação que será usada.

Ela admite 2 valores: space ou tab, definindo o estilo de indentação para, respectivamente, espaços ou tabs.

Então, se você (ou a equipe) decidiu que a indentação será com espaços, simplesmente coloque(m):

indent_size

Nesta regra, é possível estipular qual será o tamanho da indentação — outro ponto comum de choque e que, pelo bem da padronização e qualidade de código, alguns terão que ceder aos caprichos pessoais.

O valor permitido para a regra é um número inteiro que define o número de colunas usadas para cada nível de indentação.

Se, por exemplo, o tamanho da indentação for 2, a regra fica:

end_of_line

Especifica o caractere que representa a quebra de linha no código, admitindo os valores lf, cr, ou crlf.

Se isso não estiver padronizado, conflitos homéricos (geralmente evitáveis) podem acontecer no repo de códigos, e isso atrapalha bastante.

Se você não entendeu muito bem do que se trata, dê uma olhada nesta questões do Stack Overflow (em inglês).

Como exemplo, esta seria a definição de regra para o uso de lf como caractere de quebra de linha:

charset

Como você deve ter imaginado, define o charset dos arquivos (o que também é um potencial grande gerador de dores de cabeça).

Os valores que o EditorConfig permite serem usados são latin1, utf-8, utf-8-bom, utf-16be ou utf-16le.

Provavelmente, todos os arquivos .editorconfig usados por aí usam utf-8. Se você conhece algum projeto usa uma definição diferente, coloca aí nos comentários para conhecermos também.

Se quiser evitar desgostos e desventuras, use sempre:

trim_trailing_whitespace

Esta opção é um booleano que permite a definição sobre remover qualquer caractere de espaço em branco antes de nova linha.

Quer dizer, deleta sumariamente qualquer caractere em branco (não utilizado) no final das linhas de código.

Um exemplo de usar a regra para instruir o EditorConfig a apagar os caracteres em branco em final de linha é:

insert_final_newline

Especifica se os arquivos terão ou não uma nova linha no final.

Defina como true para garantir que os arquivos terminem com uma nova linha e false para garantir que não.

Exemplo de como ficaria para ter uma nova linha:

root

Para que essa regra seja bem compreendida, é preciso uma explicação preliminar.

Até então, não se tinha comentado, mas é possível criar um arquivo .editorconfig em qualquer diretório de um projeto. É possível, inclusive, que existam vários arquivos .editorconfig.

Então, o plugin do EditorConfig instalado no editor/IDE, ao encontrar um desses arquivos, vai subir na estrutura de diretórios procurando outros, objetivando saber quais regras aplicar, já que num possível conflito, vale o mais próximo na estrutura onde o arquivo consta.

root serve para parar essa procura ascendente. Quando seu valor é true, significa que não é preciso procurar por mais arquivos .editorconfig em níveis superiores de diretórios.

Apesar de esta possibilidade de usar múltiplos arquivos existir, a ilimitável maioria dos projetos usa somente 1 arquivo .editorconfig na raiz do projeto — coloca-se a regra antes da especificação dos padrões e demais regras.

Exemplos de arquivos .editorconfig

Para fixar os conhecimentos, nada melhor do que dar uma olhadinha em alguns exemplos de código EditorConfig. Assim como falado, ele é usado em grandes projetos do mundo todo.

Então, vamos a alguns exemplos de arquivos .editorconfig possíveis de serem encontrados em projetos pelas webs (no próprio site oficial, é possível ver a lista completa).

React

O arquivo do React atualmente (na data da publicação deste artigo) está assim:

Ele ilustra que é possível inserir comentários em arquivos .editorconfig usando #.

Outra coisa: você deve ter percebido que a regra max_line_length não foi abordada em nosso artigo. O motivo é que se trata de uma regra suportada por um número limitado de editores e quisemos abordar somente as regras de abrangência total.

Vue.js

O arquivo do Vue.js não foge muito do esperado:

Há definições para todos os arquivos do projeto (*), com 2 sobrescritas pontuais para arquivos *.md.

Angular

O arquivo do Angular apresenta:

O interessante é que ele sobrescreve algumas regras para arquivos específicos.

Bootstrap

Consta no arquivo .editorconfig do Bootstrap (v4-dev):

Bem padrãozinho, também, o que serve para mostrar que não é preciso inventar muito para conseguir uma padronização de estilo de código equivalente a grandes projetos.

WordPress

Para finalizar nossa mostragem de exemplos de como grandes projetos usam o EditorConfig para padronizar seu estilo de código, eis como está o arquivo do WordPress (5.4.1):

Dentre os exemplos mostrados, o arquivo do WordPress é o único em que é possível ver alguma definição de quebra de linha com crlf (mesmo assim, em um caso bem específico).

Conclusão

Padronizar estilo de códigos realmente tem a ver com qualidade? Faz do seu código mais profissional? A resposta é “Sim”, principalmente se você trabalha em equipe.

Padronização de estilos de código traz ao projeto uniformidade e consistência; em última instância, significando estabilidade e qualidade.

No fim do dia, não importa se todos usam tabs ou não, se o espaçamento é com 2 ou 4 caracteres ou se há ou não uma linha em branco no final de cada arquivo.

Egos à parte, o que importa é a adoção de um estilo de codificação comum. Lembre-se: o código do projeto deve parecer que foi escrito por uma só pessoa.

EditorConfig permite que esta padronização de coding styles seja alcançada muito facilmente, de maneira ubíqua e automatizada, mostrando-se um item indispensável no tooling de qualquer projeto com o mínimo de pretensão de qualidade.

E você, já usava EditorConfig em seus projetos? Conhecia todas as opções? Se tiver alguma dica extra de configuração, deixa aí nos comentários!