Respirando o ar no Guia de Estilo JavaScript do AirBnB

Ninguém se propõe a escrever códigos feios e de estilo inconsistente. Simplesmente acontece.

Mesmo como o único desenvolvedor em um projeto, quanto mais tempo passa e mais código você produz, mais difícil fica mais difícil manter um estilo de código consistente.

É por isso que você precisa de um guia de estilo.

Eu experimentei em primeira mão o quanto mais equipes podem realizar depois de adotar um guia de estilo.

Você não precisa mais fazer pequenos julgamentos de estilo ao longo do dia. Basta consultar o guia de estilo.

E quando um colega de equipe precisa manter seu código, é um código limpo que eles podem ler e entender.

Adotar um guia de estilo é uma das coisas mais fáceis que você pode fazer para aumentar a capacidade de manutenção do seu código - o que, em última análise, aumenta a produtividade da sua equipe. Então, vamos explorar a maneira mais popular de fazer isso.

Digite AirBnB + ESLint

O ecossistema JavaScript oferece uma ampla variedade de ferramentas e guias de estilo. Isso não deve surpreender ninguém. com JavaScript, esperamos uma grande variedade de tudo.

Mas, à medida que o ecossistema amadurece, desenvolvedores experientes começam a ansiar pela “maneira padrão” de fazer as coisas que os ecossistemas mais solidificados oferecem.

É claro que você pode passar alguns dias explorando o ecossistema JavaScript e comparando diferentes ferramentas, mas vou tentar economizar algum tempo : ESLint é a ferramenta de linting de JavaScript mais popular e o guia de estilo do AirBnB é o mais amplamente usado Guia de estilo.

Para obter mais detalhes sobre como adicionar ESLint ao seu projeto, verifique este link.

Depois de ter tudo resolvido, você pode configurar seu projeto para aplicar o guia de estilo do AirBnB instalando seu pacote npm:

npm install --save-dev eslint-config-airbnb

Adicione a seguinte linha em seu arquivo .eslintrc

"extends": "airbnb"

E voilà! Seu código agora está sujeito às regras do guia de estilo de JavaScript mais popular. Boa codificação!

Padrões são superestimados

Embora eu concorde com a maioria das regras do guia de estilo, aqui está uma lista de substituições que compilei. Esta é a aparência dos arquivos .eslintrc nas pastas raiz dos projetos:

Deixe-me explicar o raciocínio por trás de cada uma dessas personalizações em detalhes.

Recuo

A guerra entre tabs e espaços pode arruinar amizades e possivelmente até sabotar relacionamentos românticos.

Eu prefiro recuar meus espaços de código 4, embora a grande maioria dos configs por aí prefira um recuo de 2.

Meu raciocínio é que, para escrever um código limpo, indentações maiores fornecem uma representação visual melhor de quão profundo é o aninhamento em suas funções e quantos branches diferentes você tem.

Definitivamente, você não deve aninhar o código em mais de 3 ou 4 camadas dentro de um arquivo JavaScript (é um cheiro de código). Portanto, ter 4 espaços oferece melhor legibilidade, enquanto preserva outras regras, como manter seu código dentro de um limite de 80 ou 120 caracteres por linha.

Além disso, o recuo é uma das regras que respira mais “ar” no guia de estilo padrão do AirBnB. Como resultado, seu código não se aglomera tanto no lado esquerdo do editor.

Espaçamento

Este é provavelmente o maior desvio do padrão. Eu odeio código lotado. Comecei a escrever código com preenchimento de espaço extra há mais de 2 anos e nunca olhei para trás.

Então, o que essas regras significam? Bem, dê uma olhada no código a seguir. Ele respeita tecnicamente as regras do guia de estilo oficial do AirBnB.

Eu sei, é um pouco confuso. Tentei procurar uma função de complexidade média em uma das minhas bases de código, mas tive que ofuscar muito dela, então não tente entender a lógica por trás do código (porque não há nenhuma). Apenas tente ler. Tente focar, por exemplo, em variáveis ​​que são usadas em vários lugares, quando parâmetros são passados ​​para funções e onde estão as chamadas de função.

Agora dê uma olhada no mesmo código, mas com as regras de espaçamento extra aplicadas:

Não estou dizendo que é altamente legível agora, mas você pode identificar mais facilmente onde os parâmetros são enviados para as funções - especialmente em torno das funções curried.

Verifique também a diferença entre o recuo de 2 e 4 espaços nos dois exemplos.

A princípio, essas técnicas podem não parecer uma grande melhoria. Eu encorajo você a experimentá-los. Acho que você perceberá rapidamente a diferença que isso faz.

Citar guerras

Embora as duas primeiras categorias tenham alguns argumentos claros, devo dizer que a decisão das aspas simples versus duplas é altamente subjetiva.

Minha preferência por aspas duplas provavelmente vem de trabalhar muito com React, onde você mistura JavaScript com tags JSX. Como JSX está mais próximo do HTML, a tendência é adicionar atributos entre aspas duplas. Então comecei a usar aspas duplas para tudo, apenas para consistência.

Uma coisa que percebi é que é muito mais provável que você precise escrever uma aspa simples dentro de uma string de texto em inglês do que uma aspa dupla (“Estou aqui”, “Não faça isso”). Portanto, as aspas duplas podem ser mais convenientes nesses casos.

Arranjo de código

O guia de estilo oficial do AirBnB tem uma regra “não usar antes de definir”, que gera um erro se você tentar usar algo antes de defini-lo. Esta é uma boa regra - especialmente para variáveis ​​- porque você não deve depender de içamento e deve manter o problema da zona morta temporal em mente ao usar let e const.

Eu prefiro permitir que funções sejam usadas antes de serem definidas. A razão é simples: na maioria das vezes, você dividirá suas funções em subfunções menores. No entanto, a regra “não usar antes de definir” dirá a você para colocar essas subfunções antes da função original.

Mas suas subfunções existem para abstrair partes do algoritmo. Eles não devem incomodá-lo quando você abre um arquivo que contém sua função de nível superior , que você usa fora do arquivo.

Claro, isso é discutível. Mas tem impacto na depuração. Quando você itera sobre algum código e encontra uma chamada para uma função diferente, o ideal é que você consiga olhar abaixo dela ou - na pior das hipóteses - role para baixo por algumas subfunções e encontre o que está procurando.

Isso, em combinação com a declaração de função do AirBnB contra a expressão de funçãoregra,pode dar a você a liberdade de estruturar seus módulos ou bibliotecas de funções como desejar, enquanto garante que você não chamará acidentalmente uma função não inicializada.

Const over let

Aqui está outro pequeno desvio do guia de estilo. Você pode notar na minha configuração:

"prefer-const": 1

Na configuração do AirBnB, isso é definido como 2, que significa erro , enquanto 1 significa aviso .

Agora, se você não entende por que prefere const em vez de let, pode ler mais sobre ele aqui e aqui.

Quanto ao meu desvio, prefiro um aviso, pois há situações em que você não altera a atribuição de uma variável, mas altera muito o seu conteúdo.

Dê uma olhada neste código:

As regras dirão que isso está certo - o hash deve ser constante porque não é reatribuído. Mas isso nunca fez sentido para mim. Devo estar ciente de que há muitas mudanças acontecendo dentro do hash.

Vou usar let para sinalizar o fato de que a variável está sujeita a alterações. const e let devem dar mais significado às suas variáveis ​​e não devem ocultar a verdade de forma alguma.

Complexidade de código

Você pode executar a complexidade do código ciclomático para calcular a complexidade de cada uma de suas funções.

Decidir o nível máximo de complexidade é complicado. Idealmente, deve ser o mais baixo possível, o que significa que suas funções devem ter no máximo 1 ou 2 possibilidades de ramificação.

Faz sentido ter esse número o mais baixo possível da perspectiva de reutilização e teste de código. Mas há momentos em que é mais difícil quebrar funções. É por isso que vejo a complexidade mais como um aviso do que como um erro.

O importante aqui é limitar o número de funções que atingem esse limite de complexidade máxima. Mesmo em uma base de código de tamanho médio, não gostaria de ver mais de 10 funções que quebram essa regra. Então eu escolhi o valor máximo de 5, a fim de destacar essas funções. Vou direcionar essas funções quando tiver tempo para fazer alguma refatoração.

A complexidade pode ser resolvida de várias maneiras. Refatorar em funções menores é o mais óbvio. Outra opção é transformar suas instruções switch em atribuições de mapeamento.

Fizemos vários debates dentro de nossa equipe e acabamos usando 5 como valor de referência para a regra de complexidade máxima. Mas, em alguns casos, caímos para 4, apenas para ter certeza de que estamos escrevendo um código limpo e simples.

Uma nota sobre React

Como eu trabalho muito com o React e a configuração do AirBnB também contém um grande número de regras nessa área, eu queria incluir algumas de minhas preferências aqui também.

O principal objetivo das minhas substituições do React é limitar a diferenciação entre módulos JavaScript regulares e componentes React, bem como entre o código JavaScript e JSX. É por isso que escolhi um recuo semelhante e o uso de aspas duplas para todos os atributos JSX. E é por isso que prefiro deixar todos os meus arquivos com a extensão .js.

Finalmente, em relação aos componentes de classe vs. fábrica, tendo a preferir o último. Não vejo vantagem em usar classes neste momento. Posso escrever um post futuro expandindo sobre por que me sinto assim.

É sobre isso! Eu espero que você tenha gostado de ler isso. Eu agradeço seu feedback abaixo.

Se gostou do artigo, clique no coração verde abaixo, e saberei que meu esforço não foi em vão.