felipe-augusto / clean-code-javascript

Repositório original: ryanmcdermott/clean-code-javascript clean-code-javascript Índice • Introdução • Variáveis • Funções • Objetos e Estruturas de Dados • Classes • SOLID • Testes • Concorrência • Tratamento de Erros • Formatação • Comentários • Traduções Introdução Princípios da Engenharia de Software, do livro de Robert C. Martin *Código Limpo*, adaptados para JavaScript. Isto não é um guia de estilos. É um guia para se produzir código legível, reutilizável e refatorável em JavaScript. Nem todo princípio demonstrado deve ser seguido rigorosamente, e ainda menos são um consenso universal. Estes princípios são orientações e nada mais, entretanto, foram codificados durante muitos anos de experiência coletiva pelos autores de *Código limpo*. Nosso ofício de engenharia de software tem pouco mais de 50 anos e ainda estamos aprendendo muito. Quando a arquitetura de software for tão velha quanto a própria arquitetura, talvez então tenhamos regras mais rígidas para seguir. Por enquanto, deixe que estas orientações sirvam como critério para se avaliar a qualidade de código JavaScript que tanto você e o seu time produzirem. Mais uma coisa: aprender isto não irá lhe transformar imediatamente em um desenvolvedor de software melhor, trabalhar com eles por muitos anos não quer dizer que você não cometerá erros. Toda porção de código começa com um rascunho, como argila molhada sendo moldada em sua forma final. Finalmente, talhamos as imperfeições quando revisamos com nossos colegas. Não se sinta culpado pelos primeiros rascunhos que ainda precisam de melhorias. Ao invés, desconte em seu código. **Variáveis** Use nomes de variáveis que tenham significado e sejam pronunciáveis **Ruim:** **Bom:** **⬆ voltar ao topo** Use o mesmo vocabulário para o mesmo tipo de variável **Ruim:** **Bom:** **⬆ voltar ao topo** Use nomes pesquisáveis Nós iremos ler mais código que escrever. É importante que o código que escrevemos seja legível e pesquisável. *Não* dando nomes em variáveis que sejam significativos para entender nosso programa, machucamos nossos leitores. Torne seus nomes pesquisáveis. Ferramentas como buddy.js e ESLint podem ajudar a identificar constantes sem nome. **Ruim:** **Bom:** **⬆ voltar ao topo** Use variáveis explicativas **Ruim:** **Bom:** **⬆ voltar ao topo** Evite Mapeamento Mental Explicito é melhor que implícito. **Ruim:** **Bom:** **⬆ voltar ao topo** Não adicione contextos desnecessários Se o nome de sua classe/objeto já lhe diz alguma coisa, não as repita nos nomes de suas variáveis. **Ruim:** **Bom:** **⬆ voltar ao topo** Use argumentos padrões ao invés de curto circuitar ou usar condicionais Argumentos padrões são geralmente mais limpos do que curto circuitos. Esteja ciente que se você usá-los, sua função apenas irá fornecer valores padrões para argumentos . Outros valores "falsos" como , , , , , e , não serão substituídos por valores padrões. **Ruim:** **Bom:** **⬆ voltar ao topo** **Funções** Argumentos de funções (idealmente 2 ou menos) Limitar a quantidade de parâmetros de uma função é incrivelmente importante porque torna mais fácil testá-la. Ter mais que três leva a uma explosão combinatória onde você tem que testar muitos casos diferentes com cada argumento separadamente. Um ou dois argumentos é o caso ideal, e três devem ser evitados se possível. Qualquer coisa a mais que isso deve ser consolidada. Geralmente, se você tem mais que dois argumentos então sua função está tentando fazer muitas coisas. Nos casos em que não está, na maioria das vezes um objeto é suficiente como argumento. Já que JavaScript lhe permite criar objetos instantaneamente, sem ter que escrever muita coisa, você pode usar um objeto se você se pegar precisando usar muitos argumentos. Para tornar mais óbvio quais as propriedades que as funções esperam, você pode usar a sintaxe de desestruturação (destructuring) do ES2015/ES6. Ela possui algumas vantagens: • Quando alguém olha para a assinatura de uma função, fica imediatamente claro quais propriedades são usadas. • Desestruturação também clona os valores primitivos específicos do objeto passado como argumento para a função. Isso pode ajudar a evitar efeitos colaterais. Nota: objetos e vetores que são desestruturados a partir do objeto passado por argumento NÃO são clonados. • Linters podem te alertar sobre propriedades não utilizadas, o que seria impossível sem usar desestruturação. **Ruim:** **Bom:** **⬆ voltar ao topo** Funções devem fazer uma coisa Essa é de longe a regra mais importante em engenharia de software. Quando funções fazem mais que uma coisa, elas se tornam difíceis de serem compostas, testadas e raciocinadas. Quando você pode isolar uma função para realizar apenas uma ação, elas podem ser refatoradas facilmente e seu código ficará muito mais limpo. Se você não levar mais nada desse guia além disso, você já estará na frente de muitos desenvolvedores. **Ruim:** **Bom:** **⬆ voltar ao topo** Nomes de funções devem dizer o que elas fazem **Ruim:** **Bom:** **⬆ voltar ao topo** Funções devem ter apenas um nível de abstração Quando você tem mais de um nível de abstração sua função provavelmente esta fazendo coisas demais. Dividir suas funções leva a reutilização e testes mais fáceis. **Ruim:** **Bom:** **⬆ voltar ao topo** Remova código duplicado Faça absolutamente seu melhor para evitar código duplicado. Código duplicado quer dizer que existe mais de um lugar onde você deverá alterar algo se precisar mudar alguma lógica. Imagine que você é dono de um restaurante e você toma conta do seu estoque: todos os seus tomates, cebolas, alhos, temperos, etc. Se você tem múltiplas listas onde guarda estas informações, então você terá que atualizar todas elas quando servir um prato que tenha tomates. Se você tivesse apenas uma lista, teria apenas um lugar para atualizar! Frequentemente, você possui código duplicado porque você tem duas ou mais coisas levemente diferentes, que possuem muito em comum, mas su…