Boas práticas em projetos JavaScript

Compartilhe nas redes sociais

As boas práticas descritas aqui servem para assegurar que quando se está trabalhando em equipe, todas as pessoas sigam um mesmo padrão de escrita, formatação e qualidade de código.

Segundo a Wikipédia:

Boas práticas é uma expressão derivada do inglês best practice, a qual denomina técnicas identificadas como as melhores para realizar determinada tarefa.

O que vou lhes apresentar sobre boas práticas aplica-se a qualquer projeto JavaScript, no front-end ou no back-end, novo ou já existente.
Inclusive pode-se usar em projetos React, Vuejs e Angular…

Mas a fim de mostrar na prática, vou aproveitar o boilerplate front-end que estamos criando e aplicar nele.

Você pode acompanhar os outros artigos dele:

Lembrando que, a ideia da nossa estrutura base é que ela seja um ponto de partida para projetos front-end.

Hoje vamos falar sobre:

Bora la!?

Definindo um padrão de código

Aplicar e seguir um Style Guide, que é um padrão de escrita igual entre todos os desenvolvedores envolvidos no projeto, garantirá a qualidade do código e a sua organização.

— Mas de que tipo de padrão você está falando José?

Padrões sobre como escrever mesmo, por exemplo:

// padrão de um if/else

// assim
if(true){
  console.log('something')
} else{
  console.log('test')
}

// ou assim

if (true) {
  console.log('something');

} else {
  console.log('test');
}

Ou seja, com ou sem espaço entre as ‘chaves’ e ‘parênteses’.
Com ou sem ponto e vírgula ao fim das linhas.

Esse tipo de coisa pode parecer boba para alguns, mas, saiba que faz toda diferença quando se está trabalhando em equipe e pretende-se manter o código consistente e com boa legibilidade.

Essa análise pode ser feita no momento do Code Review, onde a pessoa responsável terá que ficar prestando atenção e ver se o autor do código seguiu os padrões. Mas, vamos concordar que será muito massante!

A alternativa mais saudável e eficiente é, ter uma ferramenta que faça a análise e nos reporte possíveis fugas do padrão.

ESLint

ESLint é uma ferramenta para identificar e relatar padrões encontrados no código ECMAScript / JavaScript, com o objetivo de tornar o código mais consistente e evitar bugs.

Chega de falar, vamos codar!

Instalação

npm install --save-dev eslint

Após a instalação, vamos iniciar o eslint em nosso projeto:

./node_modules/.bin/eslint --init

Algumas perguntas lhe serão feitas durante a configuração.
Minhas respostas (em negrito) foram:

  • How would you like to use ESLint?
    – To check syntax, find problems, and enforce code style
  • What type of modules does your project use?
    – JavaScript modules (import/export)
  • Which framework does your project use?
    – None of these
  • Does your project use TypeScript?
    – No
  • Where does your code run?
    – Browser
  • How would you like to define a style for your project?
    – Use a popular style guide
  • Which style guide do you want to follow?
    – Airbnb (https://github.com/airbnb/javascript)
  • What format do you want your config file to be in?
    – JSON

Após a conclusão, você terá em seu diretório root um novo arquivo chamado .eslintrc.json já com algumas configurações.

Em nosso caso usei o mesmo styleguide adotado e disponibilizado pelo Airbnb que é open source. O escolhi, pois, seu padrão me agrada e é muito adotado por diversas empresas quando se está trabalhando com JavaScript puro, ou seja, sem nenhuma biblioteca ou framework.

Porém, existem opções de padrões para quando você estiver usando React (do próprio Airbnb, Vuejs e Angular. Estão sempre disponíveis no npm, basta dar um google. 😉

Vamos testar?

Nesta parte da documentação do ESLint podemos ver várias maneiras de executá-lo e fazer a análise, por exemplo, assim:
eslint file1.js file2.js

Ou assim:
eslint src/**

Nós vamos usar a segunda opção e adicionar um script no package.json para facilitar o start do processo de lint.

Nosso script instrui o eslint a analisar os arquivos .js que estão no diretório src e em seus sub-diretórios.

package.json:

"scripts": {
  // ... outros scripts,
  "lint": "eslint src/**/*.js"
},

Agora basta rodar o comando e observar a análise acontecer:

npm run lint

No nosso boilerplate alguns anti-padrões como os abaixo foram encontrados:

O primeiro erro fala sobre a identação do arquivo e a quantidade de caracteres espaço por tab.

O segundo erro, que fala sobre LF e CRLF na verdade se refere aos linebreaks, caracteres de fim/quebra de linha.
Se você não sabe o que essas siglas significam leia essa resposta do stack overflow.

O terceiro erro fala sobre os tipos de export que estamos usando.

Vamos corrigir?

Isso ficará como tarefa para você! À medida que for solucionando os problemas, vá rodando npm run lint para ver se o lint está realmente ficando satisfeito.

Na dúvida, o código do nosso repositório já está corrigido.

EditorConfig

O EditorConfig é um padrão muito útil, principalmente para projetos onde vários desenvolvedores estão envolvidos e usando IDEs e editores de texto diferentes.

Ele tenta ajudar a garantir um padrão comum na formatação do código, o que vai facilitar o trabalho conjunto e principalmente o versionamento do código.

Trata-se de um arquivo .editorconfig, que contém instruções a respeito da identação padrão dos arquivos (tabs ou espaço? Quantos caracteres?), charset, caractere de fim de linha, etc…

Como usar

É muito simples, basta adicionar no diretório root o arquivo .editorconfig:

# EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true

# Matches multiple files with brace expansion notation
# Set default charset
[*.{js,py}]
charset = utf-8

# Tab indentation (no size specified)
[Makefile]
indent_style = tab

# Indentation override for all JS under lib directory
[src/**/**.js]
indent_style = space
indent_size = 2

# Matches the exact files either package.json or .travis.yml
[{package.json,.travis.yml}]
indent_style = space
indent_size = 2

Essas configurações de padrão lhe parecem familiares?
Pois é, são justamente alguns dos pontos que o ESLint analisa.

É automático!

A mágica vantagem do EditorConfig é que, a maioria das IDEs e editores de texto compreendem a existência desse arquivo no projeto nativamente ou com a ajuda de plugins, e ao detecta-lo tratam de ajustar sua própria configuração à configuração explícita contida no .editorconfig.

Isso faz com que os desenvolvedores que forem trabalhar no projeto não precisem configurar os padrões mencionados acima manualmente.

Tudo será configurado automaticamente quando a IDE detectar o arquivo.

Você pode ler mais a respeito no site oficial dele.

Garantindo que a análise sempre será feita

De nada adianta configurarmos nosso projeto com o ESLint se ele nunca for realmente usado.

Depender do desenvolvedor ir até o terminal e rodar npm run lint está sujeito a esquecimentos, propositais ou não.

Então, suponha comigo: esse desenvolvedor ao finalizar seu código totalmente anti-padrão, faria o commit, o push… e então teríamos em nosso repositório um código que não estaria dentro do padrão esperado.

Para garantir que o cenário acima nunca ocorra podemos usar o Husky.

Solução: Git hooks com Husky

Ele nos permite atrelar comandos específicos à operações do git.

Por exemplo, podemos mandar executar o lint toda vez antes de um commit ou antes de um push.

Caso o lint falhe, ele interrompe o commit e o push.

Isso é magnífico, pois, garante que se um código está fora do padrão, ele sequer será adicionado ao repositório. =D

Instalação

npm install --save-dev husky

Após a instalação, basta adicionar uma nova chave no nosso package.json chamada "husky" seguindo o exemplo abaixo e tudo estará concluído.

package.json:

"scripts": {
  // ... scripts aqui
},
"husky": {
  "hooks": {
    "pre-push": "npm run lint"
  }
}

Agora toda vez que tentarmos fazer um push, primeiro o eslint será executado.

Poderíamos também usar o hook “pre-commit”, mas eu particularmente não gosto. Executar o lint toda vez antes de um commit pode rapidamente se tornar um problema, caso estejamos trabalhando com commits mais atômicos.

Por hoje é só pessoal…

Quero ver todo mundo usando as boas práticas em seus projetos hein!

Até mais!