Summary of 'Clean code' by Robert C. Martin

clean_code.md

O código é limpo se puder ser entendido facilmente por todos da equipe. O código limpo pode ser lido e aprimorado por um desenvolvedor que não seja o autor original. Com capacidade de compreensão, vem a legibilidade, a capacidade de mudança, a extensibilidade e a manutenção.

---

Regras gerais

1. Siga as convenções padrão.
2. Mantenha isso simples, estúpido.
   • Mais simples é sempre melhor.
   • Reduza a complexidade o máximo possível.
3. Regra dos escoteiros.
   • Deixe o acampamento mais limpo do que o encontrado.
4. Encontre sempre a causa raiz.
   • Sempre procure a causa raiz de um problema.

Regras de design

1. Mantenha os dados configuráveis em níveis altos.
2. Prefira o polimorfismo a if/else ou switch/case.
3. Código separado de multi-threading.
4. Impedir excesso de configurabilidade.
5. Use injeção de dependência.
6. Siga a Lei de Demeter.
   • Uma classe deve conhecer apenas suas dependências diretas.

Dicas de compreensão

1. Seja consistente.
   • Se você fizer algo de uma certa maneira, faça todas as coisas semelhantes da mesma maneira.
2. Use variáveis explicativas.
3. Encapsule condições de contorno.
   • É difícil acompanhar as condições de contorno.
   • Coloque o processamento para eles em um só lugar.
4. Prefira objetos de valor dedicado ao tipo primitivo.
5. Evite dependência lógica.
   • Não escreva métodos que funcionem corretamente, dependendo de outra coisa na mesma classe.
6. Evite condicionais negativos.

Regras de nomes

1. Escolha nomes descritivos e inequívocos.
2. Faça distinção significativa.
3. Use nomes pronunciáveis.
4. Use nomes pesquisáveis.
5. Substitua números mágicos por constantes nomeadas.
6. Evite codificações.
   • Não anexe prefixos nem digite informações.

Regras de funções

1. Pequeno.
2. Faça uma coisa.
3. Use nomes descritivos.
4. Prefira menos argumentos.
5. Não tem efeitos colaterais.
6. Não use argumentos de flag.
   • Divida o método em vários métodos independentes que podem ser chamados do cliente sem o sinalizador.

Regras de comentários

1. Tente sempre se explicar no código.
2. Não seja redundante.
3. Não adicione ruído óbvio.
4. Não use comentários entre chaves.
5. Não comente o código. Basta remover.
6. Use como explicação da intenção.
7. Use como esclarecimento de código.
8. Use como aviso de consequências.

Estrutura do código fonte

1. Separe os conceitos verticalmente.
2. O código relacionado deve aparecer verticalmente denso.
3. Declarar variáveis ​​próximas ao seu uso.
4. As funções dependentes devem estar próximas.
5. Funções semelhantes devem estar próximas.
6. Coloque as funções na direção descendente.
7. Mantenha as linhas curtas.
8. Não use alinhamento horizontal.
9. Use espaço em branco para associar coisas relacionadas e desassociar fracamente relacionadas.
10. Não quebre o recuo.

Objetos e estruturas de dados

1. Esconda a estrutura interna.
2. Prefira estruturas de dados.
3. Evite estruturas híbridas (meio objeto e metade de dados).
4. Deve ser pequeno.
5. Faça uma coisa.
6. Pequeno número de variáveis ​​de instância.
7. A classe base não deve saber nada sobre seus derivados.
8. Melhor ter muitas funções do que passar algum código para uma função para selecionar um comportamento.
9. Prefira métodos não estáticos a métodos estáticos.

Testes

1. Uma afirmação por teste.
2. Legível.
3. Rápido.
4. Independente.
5. Repetível.

Código cheira

1. Rigidez.
   • É difícil mudar o software.
   • Uma pequena alteração causa uma cascata de alterações subsequentes.
2. Fragilidade.
   • O software quebra em muitos lugares devido a uma única alteração.
3. Imobilidade.
   • Você não pode reutilizar partes do código em outros projetos devido aos riscos envolvidos e ao alto esforço.
4. Complexidade desnecessária.
5. Repetição desnecessária.
6. Opacidade.
   • O código é difícil de entender.