Code Standards — Padronizando sua equipe de desenvolvimento Javascript

Excuse me but.. Your code smells

Tem problemas em implantar style guides (padrões de código) em Javascript e fazer com que este processo seja ágil e simples ? Então este tutorial é para você!

Ajude a fomentar discussões inteligentes, deixando seu comentário e likes (claps), ao fim do post 😁.

Ao assumir alguns projetos, tenho me deparado com diversos clientes com uma mesma dor, quando se trata de gerenciar grandes equipes de desenvolvimento: Padronização de codigo !

Trabalhando em equipes de software, acontecem grandes alterações a todo momento. Conforme o código cresce, sabemos a dificuldade em manter e atualizar bases de código. Cada desenvolvedor, tem sua paixão pelo código e consequentemente, pelo seu editor de texto. Todos defendem seu ambiente de desenvolvimento com unhas e dentes e na maioria das vezes, o utilizam para qualquer aplicação.

Cada editor tem seus padrões de identação, formatação e espaçamento. Caso dois usuários editem um mesmo arquivo, e o commitam (no caso do git) diversos conflitos acontecem por conta da formatação ser diferente. No exemplo, utilizando o VSCode e o Atom, alterando o mesmo arquivo, apenas trocamos o nome de uma variável, valor de uma chave e formatação, temos o seguinte erro:

Merge Changes entre códigos de editores diferentes

Além de padrões de formatação, temos alguns standards (padrões) que precisam ser seguidos. Na maioria das vezes, usamos linters, ferramentas para avaliar os padrões e qualidade de código. Um problema ao trabalhar com linters, é a forma como validamos nosso código, o processo funcionava da seguinte forma:

  1. Escrever o código
  2. Rodar o comando via terminal e exibir os erros
  3. Voltar ao código e resolver cada erro em cada arquivo separado

Meio burocrático certo ?

Tools

Nosso objetivo, é fazer com que qualquer desenvolvedor, ao submeter seu código, siga os mesmos padrões e regras em todos os projetos, de uma forma que não seja um processo doloroso para o desenvolvedor, isto é, resolver as regras de código e formatação, em um simples Ctrl + S (salvar). Para isso, vamos conhecer e trabalhar com as seguintes ferramentas:

Prettier

Um Code Formatter usado para a padronização de espaçamento e formatação de forma simples.

http://prettier.io/


ESLint

Usado para regras de semântica, além disso, resolve em tempo de "compilação" (enquanto escreve o código), side effects que possam ocorrer antes de executar seu código.

https://eslint.org/


VSCode

Editor de Texto open source, da Microsoft, que facilita a integração de todas as ferramentas e oferece diversas tarefas que rodam em background.

https://code.visualstudio.com/

Requisitos

Para nosso exemplos, precisaremos instalar os seguintes itens na máquina:

ESLint — Validação semântica de Javascript

Com o VSCode instalado, vamos precisar instalar alguns pacotes, começando pelo ESLint. Pressione Ctrl (ou Command no OSX) + Shift + P e escreva ESLint, verá uma tela similar a esta logo abaixo, clique install para instalar o pacote.

Pacote ESLint no VSCode

Em seguida, reinicie o editor. Pressione Ctrl (ou Command) + N para criar um novo arquivo, cole o código abaixo, em seguida, pressione Ctrl + S para salvar o arquivo, dê um nome para o arquivo, para nosso teste, use exemplo1.js.

Códigos ruins e sem padrões

Vá em View > Output para mostrar os logs do seu editor, repare que ele precisa de mais um pacote para que o eslint funcione.

Erro ESLint, solicitando instalação do pacote via npm

Clique na aba Terminal e digite o comando npm install -g eslint em seguida, digite eslint --version para garantir que está tudo conforme o programado, exibindo sua versão. Agora temos um novo erro, ao ver o lado inferior direito, temos uma exclamação na extensão ESLint.

Warning ESlint

Clique no item e veja a saída do Output conforme a imagem abaixo

Saida ESLit, solicitando arquivo .eslint com regras de código

Nosso ESLint precisa entender quais regras serão aplicadas, para isto, precisamos inicializar um arquivo de configuração na pasta do nosso projeto. Para inicializar um arquivo de configuração do ECMAScript Lintter, vá à aba Terminal em seguida, entre na pasta que está o seu arquivo, no meu caso o caminho é cd ~/Documents/CodeStandards/, em seguida, digite npm init -y para criar um projeto Node.js, digite também eslint --init, e escolha as seguintes opções no wizard:

  1. Use a popular style guide.
  2. Airbnb
  3. n

Repare que selecionamos um padrão muito conhecido pela comunidade de Javascript, o Airbnb. Este padrão é o responsável pelas regras de código e formatação em seus projetos. Repare que nosso editor agora está exibindo diversos problemas no código, coloque o mouse em cima do código para visualizar os erros, seu editor estará similar à imagem abaixo.

ESLint exibindo erros de semântica

Prettier

Agora, usaremos o editor a nosso favor! Vamos instalar a extensão Prettier, reiniciar nosso editor e configurá-lo para corrigir todos os erros ao salvar alterações.

Prettier, pós instalação

Para verificar se o Prettier está conforme o planejado, verifique a barra inferior direita, o ícone da extensão sendo exibido. Pressione Ctrl (ou Command) , (vírgula), para abrir as configurações de usuário no editor. Vamos inserir os seguintes dados, no arquivo de configuração exibido na tela:

"editor.formatOnSave": true, para formatar o arquivo ao salvar.

"prettier.eslintIntegration" : true, para ao formatar, corrigir os problemas de regras de código a partir de nosso .eslintrc.

Uma observação importante, ao ativar o Prettier para formatar e corrigir erros de semântica, pode ser que seu editor não mostre erros e após salvar o arquivo, o prettier tornar seu código inválido. Para evitar este conflito, adicionamos regras customizadas na configuração

"prettier.trailingComma" : "all",
"prettier.singleQuote" : "true",

Seu código final ficará similar ao código abaixo

Código completo de nossas configurações do Editor
Ao trabalhar com o Typescript Lint, é importante desabilitar o ESLint no editor, pois as extensões conflitam entre si.

Correção semântica do arquivo

Volte ao seu arquivo e pressione Ctrl (ou Command) + S, repare algumas das regras definidas pelo AirBnb Style Guide foram corrigidas. Aspas duplas para simples, ponto e vírgulas, automagicamente! But, alguns dos erros ainda não foram corrigidos, com o mouse em cima da linha, podemos entende-los através sequencias de alerta. Abaixo, a primeira linha, validando o padrão de nomenclatura para criação de funções:

[eslint] Identifier ‘bool_FUNCAO_DOIDONA’ is not in camel case. (camelcase)

Vamos alterar nosso código e deixá-lo como o abaixo, repare que o eslint não corrige todas as regras, algumas como erros no fluxo de dados (code smells, ou código fedido), não serão removidos, apenas alertados. Nestes casos, devemos alterar seguindo as convenções de código definidas pela linguagem.

Adicionando exceções ao ESLint

Repare que o console.log ainda é exibido como erro para o editor, podemos configurar para ignorar esta regra. No arquivo .eslintrc.js deixaremos com o seguinte código, adicionando o objeto rules, com o numero 0 para desabilitar a regra.

Conclusão

Sabemos que padronizar e implantar regras em seu time pode ser um processo um pouco doloroso, desta forma, resolvemos o problema de muitos trabalharem em um mesmo projeto, modificando um mesmo arquivo e acontecer de merges por formatação diferente. Outro ponto é que o Prettier e ESLint funcionam em boa parte dos editores. Em nosso time, alguns desenvolvedores trabalham com VSCode e outros Atom e não temos mais problema :D


Se chegou até aqui, já é um vencedor! Ajude a fomentar discussões inteligentes, como comentários logo abaixo.Não esqueça também de deixar diversos likes (claps) no post.