O documento fornece diretrizes sobre como escrever códigos limpos e de alta qualidade, focando em tópicos como: uso de nomes significativos, comentários concisos, métodos pequenos que fazem uma única coisa, poucos parâmetros por método, boa formatação e estrutura do código. Além disso, aborda a importância de testes automatizados e métricas que medem a complexidade e qualidade do código.
8. clean code
● Se um nome necessita de um comentário, então ele não revela o
seu propósito
● O nome de uma variável jamais deve conter a palavra variável, o
nome de uma tabela jamais deve conter o nome tabela/table
● Facilite a busca, não use só uma letra como nome ou só um número
● O tamanho do nome deve ser proporcional ao tamanho do escopo
9. clean code
● A diferença do programador amador e do profissional é que o
profissional entende que clareza é fundamental e não tenta ficar se
exibindo com códigos super difíceis.
● Nome de metodos devem ser verbos, exemplo: postar_pagamento,
excluir_pagina, salvar_pessoa
10. clean code
● Definir um padrão de nomenclatura, não utilizar verbos diferentes.
Exemplo: obter_pessoa(), recuperar_pessoa(), pegar_pessoa(). É
preciso estabelecer um padrão e usar o mesmo verbo em classes
diferentes. Exemplo: obter_pessoa() na classe pessoa,
obter_cliente() na classe cliente.
● Usar uma palavra por conceito. Por exemplo: para exclusão, utilizar
a palavra excluir nos métodos de exclusão de todas as classes,
para recuperar utilizar obter em todas as classes, etc.
13. clean code
● Não insira comentários em código ruim, reescreva-o
● Desejamos colocar comentário pois nem sempre encontramos uma
forma de nos expressar sem eles
● Quando estiver em uma situação que seja colocar comentários no
seu código, pense bem se isso não pode ser transcrito no código
● Comentários errados ou desatualizados são piores que nenhum
comentário
15. clean code
● Fazer o método em passos, ou seja, um método principal com
varios dentro
● O programa deve ser lido como se fosse uma série de parágrafos,
cada um descrevendo o nível atual e fazendo referência aos
parágrafos consecutivos
● Métodos devem ser pequenos
17. clean code
● Blocos dentro de if/else/while devem ter apenas uma linha, uma
chamada a um método (método com um nome significativo)
18. clean code
● Os métodos devem fazer apenas uma coisa (coesão)
● O código deve ser lido de cima para baixo com uma narrativa (regra
decrescente)
● Princípio de responsabilidade única
19. clean code
● Antigamente se falava que as funções/métodos devem caber no
monitor, mas isso era no passado, os monitore eram menores e às
fontes maiores. Hoje um método não deve passar de 20 linhas. O
ideal é ter 4 ou 5 linhas.
21. clean code
● Usar 3 no máximo parâmetros
● Passar um booleano por parâmetro é uma péssima prática, pois
além de dificultar o entendimento da assinatura do método, mostra
explicitamente que o método faz mais de uma coisa. Criar dois
métodos ao invés de um que receba true e false
● Evitar muitas condições no mesmo if, refatorar essas condições
para um método
22. clean code
● Deve ser evitado parâmetros de saída em um método, caso precise
alterar o estado de algo, faça mudar o estado do objeto que
pertence.
● Evite: public void adicionar_rodape(relatorio){}
● Melhor fazer assim: relatorio.adicionar_rodape();
23. clean code
● Colocar os blocos que estiverem dentro do try em um outro método,
não deixar tudo no mesmo bloco (os métodos devem fazer apenas
uma coisa e tratar o erro é só uma coisa)
25. clean code
● Agrupar em blocos os códigos que estão intimamente ligados,
como por exemplo duas variáveis
● Declaração de variável: deve-se declarar as variáveis o mais
próximo possível de onde serão usadas
● Variáveis de instância devem ser declaradas no início da classe
26. clean code
● Métodos dependentes devem ficar próximos. De preferência quem
estiver chamando deve ficam em cima.
● O espaço em branco deve ser usado para separar operações, sinais
(+-*/) e assinatura de metodos com parametros.
31. clean code
● Quanto maior a cobertura de testes menor o medo (100% cobertura
de testes existe?????)
● Os testes não devem ter qualidade menor do que o código de
produção, pois o código de produção evolui e os testes devem
evoluir junto
● Os códigos de teste são tão importantes quanto os códigos de
produção
32. clean code
● Se não mantiver seus testes limpos irá perdê-los e terá que fazer de
novo
● Um método de teste deve ter um único assert, pois isso mostra que
que o testes faz uma única coisa (mesma lógica nos
métodos/funções)
33. clean code
● Como testar esse código?
● Quantos testes serão
necessários para validar
todas as condições?
36. clean code
● Indica a complexidade que um trecho que código possui
● O resultado da complexidade ciclomática indica quantos testes
(pelo menos) precisam ser executados para que se verifique todos
os fluxos possíveis que o código pode tomar, a fim de garantir uma
completa cobertura de testes.
39. clean code
● Esta é uma métrica de complexidade de código que indica que uma
classe não pode ter muitos métodos
● Geralmente, se uma classe possui muito métodos ela não é coesa,
ou seja, não faz uma única coisa.
41. clean code
● Uma classe que possui muitos filhos ou mais que três pais, gera um
alto nível de acoplamento no código, além de aumentar
drasticamente a complexidade
● Deste caso, o programador deve, conhecer os metodos da classe
atual, e os métodos de todas as classes pai.
44. clean code
● Código duplicado quebra um dos princípios da orientação a objetos
que é reutilização de código
● Programadores duplicam código para mostrar “trabalho” (métrica
de commit), e por dificuldade de entender o código já existente
● Corrigir bugs em dois lugares
● Duplicar testes