Padronização de código com (ESLint e EditorConfig)

Utilizando ferramentas que irão aumentar sua produtividade e te proteger de você mesmo.

📌 Índice

• Introdução
• EditorConfig
• ESLint
• Prettier
• Configurações
  • Configurando o EditorConfig
  • Configurando o ESLint
• Finalizando

✨ Introdução

Por diversas vezes, passei pelo termo padronização de código e ele estava ligado a projetos de empresas com alguns desenvolvedores trabalhando. Com isso, em um primeiro momento, me perguntei: se trabalho sozinho em um projeto, pra que me preocupar em padronizar o código ou os commits (artigo sobre padronização de commits)?!

Inclusive, li um artigo muito bacana sobre isso no IMasters, voltado para a padronização de código em equipes, vou deixar ele AQUI para você conferir depois.

Ao começar a estudar mais padronização de código, me deparei com diversas bibliotecas e configurações que poderia utilizar. Nesse momento, comecei a testar e entender o que é interessante usar em um projeto pessoal e o que pode ficar para outros projetos maiores.

Hoje, estou configurando o ESLint em todos os meus projetos, pois ele acaba ajudando muito na produtividade e com isso consigo manter uma padronização de código entre os meus próprios projetos, o que ajuda muito quando preciso fazer alguma manutenção ou desenvolver novas funcionalidades.

Nesse artigo, falarei sobre as ferramentas e configurações que utilizo atualmente em meus projetos. Deixarei também algumas dicas de configurações que faria para projetos com mais devs.

Primeiramente, contextualizarei sobre as ferramentas que usaremos e depois mostrarei o passo a passo para se fazer as configurações. Dessa maneira, será prático revisitar esse artigo quando precisar criar um projeto e seguir o passo a passo da configuração.

✨ EditorConfig

Existem várias configurações que os editores trazem por padrão, por exemplo:

• Se a indentação vai ser feita com espaços ou tabs
• O tamanho da indentação, se vai ser de 2 ou 4 espaços por exemplo
• O charset que está sendo utilizado
• Entre outras...

Em alguns casos, pode acontecer de você utilizar uma indentação de 2 espaços e uma nova página ser criada com 4 espaços ou vice-versa. Esse problema se torna um pouco maior caso haja mais devs no projeto, pois cada um pode preferir uma configuração ou estar utilizando outro editor com configurações diferentes, o que pode bagunçar um pouco o código.

E é aí que entra o EditorConfig. Com ele podemos criar um arquivo de configuração que vai padronizar as configurações entre os editores. Com isso, no projeto em que ele estiver configurado as configurações padrões do editor vão ser substituídas, fazendo com que em qualquer situação tenhamos arquivos padronizados independentemente de gostos ou editores diferentes.

✨ ESLint

O ESLint implementa o processo de Linting, que é responsável por aplicar regras a uma base de código e destacar padrões ou códigos problemáticos, sem a necessidade do código ser executado. No site dele encontramos a descrição "Encontre e corrija problemas em seu código JavaScript", mas ele pode ser usado também com Typescript.

Para podermos usufruir de todo o poder do ESLint é importante seguirmos algum guia de estilo para o nosso código. Dentre os vários guias existentes, um dos mais famosos é o do Airbnb e um que gosto bastante de usar que é o Standard.

Um guia de estilo define regras e padrões que seu código deve seguir. Por exemplo, o guia do Airbnb usa aspas duplas e ponto e vírgula no final da linha. Particularmente, gosto de usar aspas simples e não finalizo a linha com o ponto e vírgula (o código fica muito feio com eles e é totalmente opcional), o que se adequa mais às regras do Standard.

Não existe muito isso de qual é certo ou errado, o importante é você escolher um e seguir. Podemos modificar as regras que vêm por padrão em um guia ou até mesmo criar novas regras, vamos ver isso mais pra frente na seção de configurações.

A coisa que é mais legal depois de configurar o ESLint, motivo por qual eu estou configurando ele em todos os projetos que trabalho, é o fato de conseguimos automatizar boa parte dos ajustes no código, o que agiliza muito na hora de codar.

Uma coisa que me incomodava no auto-import do VS Code, é que às vezes ele faz o import com aspas duplas e ponto e vírgula, quando isso acontecia eu tinha que mudar manualmente as aspas e apagar o ponto e vírgula. Com o ESLint devidamente configurado, basta salvar o arquivo e o código vai ser ajustado automaticamente (isso ajuda muito).

✨ Prettier

Uma outra ferramenta muito utilizada na padronização do código é o Prettier. Ele complementa o ESLint e faz ajustes que ele não faria sozinho. Por exemplo, se você tem uma linha com 100 caracteres ele vai quebrar e indentar a linha automaticamente, trabalhando mais na estrutura do código do que se preocupando com um guia de estilos que ele tenha que seguir.

O Prettier é uma ferramenta fantástica, vou deixar o link da documentação dele AQUI para mais informações. Não vamos configurar ele nesse artigo, geralmente não configuro ele em meus projetos e vou explicar o porque.

Automatizar a organização do código é muito legal e pode ser uma ótima ferramenta, mas isso tira um pouco da sua liberdade e engessa um pouco o código. O Prettier acaba fazendo várias formatações no código e às vezes eu não queria o código com o formato que ele sugeria. Gosto do processo de formatar o código e o Prettier acaba passando um pouco por cima disso. Em projetos que estou trabalhando sozinho, o ESLint é o suficiente para me ajudar, já o trabalho que o Prettier faz, gosto de fazer manualmente.

Então em qual momento eu adicionaria o Prettier em um projeto?

Em projetos Open Source que eu sei que as chances de receber Pull Requests são grandes e se estivesse em uma equipe com outros devs, caso percebesse que nem todos tem a mesma preocupação que eu de deixar o código bonito e organizado. Nesses casos, acho que faz total sentido o uso do Prettier, dessa forma garantimos que todos estão respeitando a organização do código.

✨ Configurações

Será necessário um projeto para fazer a configuração do EditorConfig e ESLint. Você pode seguir esse meu outro artigo para aprender a criar um projeto com Next e Typescript: Iniciando um Projeto com NextJS e Typescript.

Ou pode criar um projeto simples abrindo uma pasta no seu editor e rodando o comando yarn init -y ou npm init -y.

Com o projeto iniciado, podemos começar as configurações.

✨ Configurando o EditorConfig

Para configurar essa ferramenta, iremos precisar de uma extensão do VS Code chamada EditorConfig for VS Code, ela também existe para outros editores.

Com a extensão instalada, podemos clicar com o botão direito sobre o explorador de arquivos do projeto e selecionar a opção Generate .editorconfig e então um arquivo de configuração vai ser criado.

O arquivo vai ser gerado com as seguintes configurações:

root = true

[*]
indent_style = space
indent_size = 2
charset = utf-8
trim_trailing_whitespace = false
insert_final_newline = false

Nesse arquivo podemos ver algumas opções como o tipo de indentação, o tamanho da indentação, qual o charset que está sendo utilizado e algumas outras configurações. Pode ser que o seu indent_size esteja com 4 e não com 2, fica a seu critério modificar essa opção, mas por convenção usamos 2.

Vamos começar modificando as 2 últimas opções, trim_trailing_whitespace e insert_final_newline, de false para true. Trim_trailing_whitespace vai retirar os espaços desnecessários que às vezes deixamos no final da linha ou em uma linha em branco e insert
_final_newline vai adicionar sempre uma linha em branco no final do arquivo, o que deixa o diff do git mais bonito e facilita a inserção de uma nova linha.

Por fim, caso não exista no arquivo, adicionaremos mais uma configuração, a end_of_line = lf, para garantir que as quebras de linha sejam padronizadas. No Windows o final das linhas são representadas por \r\n (um link para quem quiser saber o porquê), já no Linux e Mac são apenas com \n , então para evitar que isso gere algum tipo de problema adicionamos essa configuração.

No final, o seu arquivo deve estar assim:

root = true

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

Podemos também fazer a configuração do trim_trailing_whitespace e insert_final_newline direto no VS Code. O EditorConfig busca as configurações do editor para criar o arquivo, dessa maneira não vamos precisar fazer essas modificações quando criamos o próximo arquivo.

Para acessar as configurações do VS Code, digite CTRL+SHIFT+P e pesquise por Open Settings (JSON), clique na opção e irá abrir um arquivo JSON com as configurações do editor.

Basta colocar as seguintes configurações no arquivo e salvar:

"files.insertFinalNewline": true,
"files.trimTrailingWhitespace": true,
// Opcional
"editor.tabSize": 2,
"editor.rulers": [100],

✨ Configurando o ESLint

Antes de iniciar de fato a instalação e configuração do ESLint no nosso projeto, precisamos instalar a extensão do ESLint no VS Code. Ela vai ajudar a fazer com que o código seja ajustado automaticamente e vai destacar os erros que encontrar no nosso código.

Agora, precisamos inserir mais algumas propriedades no arquivo de configuração do editor.

Para acessar as configurações do VS Code, digite CTRL+SHIFT+P e pesquise por Open Settings (JSON), clique na opção e irá abrir um arquivo JSON com as configurações do editor.

Adicione as seguintes linhas no arquivo:

"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
  "source.fixAll": true,
},

Por padrão, o VS Code já tem uma funcionalidade que te ajuda a indentar o código, basta clicar com o botão direito em cima do código e ir na opção Format Document.

Com essas configurações, sempre que salvar um arquivo ele será formatado automaticamente, mesmo não tendo o ESLint instalado. Isso vai te ajudar a manter o código sempre indentado e quando o ESLint estiver configurado, ele já irá formatar seguindo as regras dele.

Agora, vamos para a instalação. As instruções utilizarão o yarn, mas pode ser substituído pelo npm se preferir.

# O -D indica que vamos instalar a lib como uma dependência de desenvolvimento
yarn add eslint -D

# Comando para inicializar o ESLint
yarn eslint --init

O ESLint traz um guia que vai nos ajudar a fazer a instalação, só precisamos responder as perguntas.

1 - How would you like do use Eslint? (Qual a forma que queremos utilizar o Eslint)

• To check syntax only ⇒ Checar somente a sintaxe
• To check syntax and find problems ⇒ Checar a sintaxe e encontrar problemas
• To check syntax, find problems and enforce code style ⇒ Checar a sintaxe, encontrar problemas e forçar um padrão de código

Escolheremos a última opção To check syntax, find problems and enforce code style.

2 - What type of modules does your project use? (Qual tipo de módulo seu projeto usa?)

• JavaScript modules (import/export)
• CommonsJS (require/exports)

Geralmente vamos utilizar a primeira opção Javascript modules (import/export), a menos que esteja trabalhando em um projeto de Back-end com uma versão do Node que não suporta os Modules, ou em alguma outra situação que demande o uso do CommonsJS.

3 - Which framework does your project use? (Qual framework seu projeto está utilizando?)

• React
• Vue.JS
• None of these

Se for um projeto Back-end escolha a opção None of these. Se estiver criado o projeto seguindo meu artigo de Next.js, escolha React.

4 - Does your project use TypeScript? (Seu projeto está utilizando Typescript?)

• No
• Yes

Se estiver seguindo meu artigo de Next.js, selecionar a opção Yes.

5 - Where does your code run? (Onde seu código está rodando?)

• Browser
• Node

Se for um projeto com o Next.js, utilize a tecla Espaço e marque as duas opções.

6 - How would you like to define a style for your project? (Qual guia de estilo queremos utilizar?)

• Use a popular style guide ⇒ Padrões de projetos já criados anteriormente por outra empresa
• Answer questions about your style ⇒ Criar seu próprio padrão de projeto

Selecione a primeira opção Use a popular style guide

7 - Which style guide do you want to follow? (Qual guia de estilo você deseja seguir?)

• Airbnb: https://github.com/airbnb/javascript
• Standard: https://github.com/standard/standard
• Google: https://github.com/google/eslint-config-google

Selecione a segunda opção Standard. Em um outro momento você pode testar os outros guias.

8 - What format do you want your config file to be in? (Qual formato de configuração do Eslint que você deseja salvar?)

• Javascript
• YAML
• JSON

Selecione a opção JSON.

Nesse ponto, o ESLint irá te informar quais as dependências necessárias de acordo com as opções que foram selecionadas.

9 - Would you like to install them now with npm? (Você deseja instalar as dependências agora utilizando npm?)

Caso esteja utilizando o Npm a resposta é Yes.

Com o Yarn temos duas opções.

• A mais simples (ou preguiçosa, geralmente eu uso essa) é responder sim. Desse modo, as dependências serão instaladas com o npm, o que vai fazer com que demore um pouco mais. Ao finalizar, o npm vai criar um arquivo package-lock.json que precisamos apagar, e em seguida precisamos rodar o comando yarn no terminal para mapear as dependências que foram instaladas com o npm no arquivo yarn.lock.

• Ou podemos instalar as dependências manualmente. O primeiro passo é selecionar as dependências que apareceram no seu terminal e copiar. No terminal não conseguimos copiar o texto com o atalho CTRL+C precisamos usar CTRL+SHIFT+C ou clicar com o botão direito do mouse e ir em copiar.

  Para instalar, começamos com o comando yarn add -D e colamos as dependências que copiamos. O comando vai ter essa estrutura:
  

  # Não copie o comando abaixo, é só um exemplo.
  # As versões mudam constantemente, use as que esta no seu terminal.
  
  yarn add -D eslint-plugin-react@latest @typescript-eslint/eslint-plugin@latest eslint-config-standard@latest eslint@^7.12.1 eslint-plugin-import@^2.22.1 eslint-plugin-node@^11.1.0 eslint-plugin-promise@^4.2.1 || ^5.0.0 @typescript-eslint/parser@latest
  
  

Após finalizar a instalação, você vai notar um arquivo .eslintrc.json na raiz do seu projeto. Dentro desse arquivo, no final dele, existe um campo de regras que provavelmente está vazio, vamos adicionar essas regras no arquivo:

"rules": {
  "react/prop-types": "off",
  "react/react-in-jsx-scope": "off",
  "space-before-function-paren": "off",
  "no-console": "warn",
  "comma-dangle": [
    "error",
    "always-multiline"
  ],
  "jsx-quotes": [
    "error",
    "prefer-double"
  ]
}

Vou te explicar as regras, e se quiser mais informações é só pesquisar pela regra no Google.

• react/prop-types e react/react-in-jsx-scope são validações do React que não são necessárias, então desativamos elas.
• space-before-function-paren, o Standart coloca um espaço entre o nome da função e os parênteses, dessa maneira: function teste () entretanto, não gosto desse padrão então desativo essa regra, assim os parênteses ficam colados no nome da função function teste()
• no-console, já aconteceu algumas vezes de eu esquecer algum console.log no código sem querer, em algum teste que estava fazendo. Então passei a configurar essa regra, ela vai gerar um alerta em todos os consoles do código, e com isso eu sempre lembro de retirá-los antes de commitar.
• comma-dangle, eu sempre gosto de manter a última vírgula dentro de um objeto JS, pois deixa o diff do git mais bonito e é mais prático para adicionar uma nova propriedade se necessário, essa regra irá sinalizar quando estiver faltando a vírgula.

• jsx-quotes, no JS ou TS eu gosto de usar aspas simples, mas no HTML ou JSX eu mantenho as aspas duplas, pra mim faz sentido que seja assim já que o JSX se assemelha muito ao HTML, essa regra sinalizará isso.

  Cheguei a ler várias discussões sobre essa regra na internet, alguns consideram uma boa prática, outros não, então fica a seu critério. No final, quando salvar o arquivo, o ESLint vai organizar esses detalhes no código, então é tranquilo.

Pra finalizar, é interessante criar um arquivo .eslintignore e de preferência copiar o conteúdo do arquivo .gitignore do seu projeto e colar nele.

✨ Finalizando

Em um primeiro momento pode parecer muita coisa tudo que vimos, mas não é, só parece porque é algo novo. Quando for fazer a configuração pela segunda vez já vai estar bem mais simples.

Não deixe de fazer essas configurações em um projeto para você testar, garanto que vai te ajudar. Não só vai aumentar a sua produtividade por estar automatizando uma tarefa que está fazendo manualmente (ou pelo menos deveria estar, né 👀), como também vai elevar o nível do seu código, deixando-o mais profissional e mostrando que você se importa com a organização e indentação dele.

Espero que esse artigo tenha somado para você de alguma forma. Você pode entrar em contato comigo para me passar um feedback ou trocar uma ideia pelo Linkedin ou Instagram. Deixarei também o meu GitHub por aqui e meu site vitordevsp.com.br, no qual você pode encontrar mais conteúdos criados por mim.