Thread by @rogermelodev

Nessa thread, você aprenderá:

✅ Como pegar bugs antes de executar seu código;
✅ As 3 principais verificações que um linter executa;
✅ Como utilizar um linter em um projeto;

Vem comigo! 👇

🔥 O que é um linter?

Um linter é uma ferramenta responsável por analisar, de forma automatizada, o código fonte de uma aplicação e indicar bugs existentes nela.

Qual ferramenta de linter você utiliza em seus projetos?

🔥 O que é um bug?

"Bug" é apenas uma palavra utilizada em casos onde o código não funciona.

Curiosamente, a origem da palavra "bug" vem de termos antigos de nomes relacionados à monstros.

🔸 Bugbear
🔸 Bugaboo
🔸 Boogeyman

Mas, por que "bug"? Na verdade, o termo foi utilizado pela 1ª vez aqui:

Em 1947, a marinha americana utilizava o Harvard Mark II, computador programado e construído por Grace Hopper e Howard Aiken, para executar cálculos.

Em 9 de Setembro, os resultados dos cálculos começaram a não fazer sentido.

Ao abrirem o computador para investigar, descobriram a causa do problema: uma mariposa presa no relay.

Os operadores a removeram cuidadosamente com uma pinça, prenderam ela com durex no log report, e escreveram "First actual case of bug been found".

Desde então, o termo "debugging" é representado como "remover o bug do computador, para que ele volte a funcionar".

Portanto, em uma aplicação, bug é um sinônimo para "erro", 99.999% das vezes causado por nós, programadores(as).

🔥 JSLint, JSHint e ESLint

Sim, nós criamos bugs o tempo todo.

E o objetivo de um linter é pegar esses erros.

Em 2002, Douglas Crockford desenvolveu e lançou o 1º linter de JavaScript, o JSLint.

Em 2011, Anton Kovalyov forkou o JSLint e lançou o JSHint. Um linter mais configurável, com mais regras e outras melhorias.

Em 2013, Nicholas C. Zakas lança o ESLint, com mais regras de qualidade e estilo de código e um sistema de plugins que permite que o desenvolvedor(a) crie suas próprias regras.

Atualmente, o ESLint é o linter mais popular entre Desenvolvedores(as).

* Fonte: ashleynolan.co.uk/blog/frontend-…

🔥 O que um linter verifica

Um linter checa 3 pontos principais em uma aplicação:

1️⃣ Erros cometidos pelo Programador(a)

Esse ponto é o mais crítico. Qualquer erro que o linter pega aqui é uma dor de cabeça à menos que você terá que lidar.

Existe a possibilidade de você executar seu código e, no momento da execução, verificar se há algum erro.

Isso é o que testes unitários e de integração fazem. Em ambos os casos, é necessário que você execute o código para que os erros sejam detectados.

Porém, um linter pode te ajudar a pegar esses erros com um loop de feedback mais curto, através da análise estática.

Você vê o erro no código à seguir?

Esse código causa um loop infinito ao ser executado.

O loop está indo na direção errada, "i" sempre será menor que 10.

Sem um linter, esse bug será detectado no momento em que você executar o código.

Com um linter como o ESLint, por exemplo, o bug é detectado 👉antes👈 do código ser executado.

2️⃣ Boas práticas

Boas práticas são sobre evitar confusão no código, padrões que geralmente levam à erros.

Um código pode funcionar normalmente, mas ainda assim causar confusão ao ser lido por outra pessoa.

Um linter minimiza o risco de uma escrita confusa de código.

Em termos de sintaxe, o código abaixo não está incorreto, mas omitir as chaves pode ser arriscado.

Dias depois, alguém pode adicionar uma segunda expressão após a invocação da função "incremment".

3️⃣ Estilo de código

Aqui, são verificados espaços, tabs, pontuações e outros aspectos de formatação de código.

O objetivo dessa verificação é que o código seja consistente, a ponto de parecer que foi escrito por apenas uma pessoa.

Esses 3 pontos economizam tempo em code reviews. Ao fazer a revisão do código, você não terá que lidar com problemas de estilo e formatação, e focará no que realmente importa.

🔥 Como utilizar um linter em um projeto

Vou demonstrar, de forma rápida, como você pode instalar o StandardJS em um projeto.

Irei instalá-lo no tdd-playground, um projeto que utilizo nas threads sobre TDD. Você pode cloná-lo aqui:

github.com/Roger-Melo/tdd…

🔶 O que é o StandardJS

O Standardjs é um set de configurações que utiliza o ESLint por baixo dos panos.

Existem outras alternativas, como o set do Airbnb ou o do Google, que são populares também.

Não importa qual deles você (ou o seu time) escolha. Apenas escolha e não olhe pra trás. Não caia no limbo da indecisão de qual set usar.

🔶 Sério, não olhe pra trás

.eslintrc são arquivos que definem as regras do ESLint que serão utilizadas em uma aplicação.

E, dentro do .eslintrc, essas regras podem ser sobrescritas.

É possível extender o set do Airbnb como linter a ser utilizado na aplicação, mas sobrescrever uma regra de aspas duplas, por exemplo.

Em um time desorganizado, qualquer pessoa pode redefinir uma regra baseada em aspectos subjetivos.

🔶 Por que uso o StandardJS

Arquivos `.eslintrc.*` podem chegar a ter cerca de 2.000 linhas de código.

Se você, assim como eu, quer poupar tempo e energia, o StandardJS cairá como uma luva.

Por baixo dos panos, ele possui as mesmas centenas de linhas de configurações, mas as empacota e entrega apenas uma interface de linha de comando, que você executa e pode adicionar à sua suíte de testes.

Ou seja, a configuração está pronta, é só instalar e usar. Não há dores de cabeça com configurações manuais entre projetos.

🔶 Instalando e configurando o StandardJS

Para instalá-lo, basta executar `yarn add --dev standard` ou `npm install --save-dev standard`:

Após a instalação, você pode executá-lo e obter o feedback do que está ou não de acordo com as regras definidas:

Essa é a forma mais fácil e rápida de você instalar e começar a utilizar um linter em sua aplicação. Sem instalar multiplos packages e ter que descobrir a configuração de cada regra.

E quais são as regras definidas? Algumas delas são:

🔹 Utilizar === ao invés de ==;
🔹 Sempre tratar um parâmetro de erro em uma função;
🔹 Não utilizar ponto e vírgula \o/

Você pode ver a lista completa delas aqui: standardjs.com/rules.html

Algumas regras podem ser aplicadas de forma automática, sem a necessidade de você abrir o arquivo e modificá-lo. Basta executar `yarn standard --fix`.

Este comando é ideal para quando você adiciona o linter em um projeto já existente,

que ainda não tinha regras de lint a serem seguidas, ou quando você está trabalhando em algum projeto sem executar o linter por um tempo, e quando executa, há vários erros que precisam ser corrigidos.

🔥 E se eu quiser utilizar o ESLint diretamente?

É uma escolha válida, mas fique atento aos "gotchas".

🔶 Margem para opiniões subjetivas

Como mencionei levemente acima, pessoas do seu time irão propor mudanças de regras de acordo com seu estilo pessoal.

E de repente, você se vê em um debate de prós e contras de tabs vs spaces, por dias, ou semanas.

Esses tipos de debate consomem tempo e energia e o resultado é insignificante.

🔶 Duplicação

Se você tem múltiplos repositórios a serem gerenciados, não é viável checar um .eslintrc gigantesco com múltiplas linhas de configuração para cada um.

Neste caso, o recomendado é criar uma configuração compartilhável e publicá-la como um pacote do NPM.

E fazer com que cada um dos repositórios dependam desse pacote.

Dessa forma, se você quer modificar algo na configuração, a mudança é feita em apenas um lugar.

🔥 E o Prettier?

É uma ótima ferramenta, mas apenas para formatação.

O Prettier não eliminará a necessidade de um linter para cuidar dos erros e das boas práticas em uma aplicação.

E principalmente, por si só, o Prettier não cumpre o papel fundamental de um linter: pegar bugs antes de executar o código.

Acha que esse conteúdo pode ajudar + pessoas❓

👉Retweeta👈 essa thread!

Linkei o início dela ali
em baixo, para facilitar =)

https://twitter.com/rogermelodev/status/1196099814804611074

Baixe meu eBook gratuito e com exercícios 👇

https://twitter.com/rogermelodev/status/1179150503403491331

Referências:

eslint.org

jshint.com

jslint.com

ashleynolan.co.uk/blog/frontend-…