O documento discute princípios de código limpo, incluindo escrever código com nomes significativos e descritivos, manter funções pequenas e focadas em uma única tarefa, e estruturar o código em classes pequenas com responsabilidades bem definidas.

1. Código Limpo
@marcelotozzi | www.marcelotozzi.com
marcelotozzidelima@gmail.com | Talk

3. A cozinha...

6. O código ruim já te atrapalhou?
Por que ele foi escrito assim?
Bem provável!

7. Você achou que não teria
tempo pra fazer um bom
trabalho?

8. Seu chefe ficaria p*** se você
demorasse mais por um bom
código?

9. Saco cheio daquele código?

10. Mais coisas pra fazer?

12. Produto extraordinário.
Vários bugs.
Release apressado.
O código ficou uma zona!
O código ruim acabou com
a empresa!

14. #comofaz?

15. + pessoas.
Não conhecem.
Pressão.
Quanto mais confuso, menor
a #produtividade.
piorar++

16. Um dia alguém vai ler seu código.

17. Regra do escoteiro
“Deixe a área do acampamento mais
limpa do que como você a encontrou.”

18. Nomes significativos

19. Revele
propósito!
Bons nomes todos
entendem.

20. Evite informações erradas
Palavras com
significado que
podem desviar do
que desejamos passar.

21. Um atributo accountList...
E se não for um List?
E se for uma String?
accountList.concat()?
accountList.substring()?
accountList.toLowerCase()?

22. Nomes de classes
Use substantivos como:
Client, WikiPage, Account...
Evite palavras como:
Manager, Processor, Data, Info...
Não use verbos.

23. Nomes de métodos
Use verbos:
postPayment, deletePage, save
Métodos de acessos:
get / set / is

24. Funções

25. Devem ser
pequenas
Fazer
apenas uma
coisa

26. •Abstração maior para menor.
•O código deve poder ser narrado.

27. Evite fazer coisas escondidas

28. DRY

29. Comentários

30. “Não insira
comentários num
código ruim,
reescreva-o.”

31. Comentários legais
• Licensas de software.
• //TODO’s.
• JavaDoc em APIs Públicas.

32. Comentários ruins
Históricos de alteração.
Comentários óbvios.
Autoria.
Evite comentários se é
possível usar um método
ou variável.

33. Estruturas de dados

34. Lei de Demeter
Você manda o cachorro andar ou as patas?
#Encapsular o comportamento e a
complexidade.

36. Tratamento de erro
As coisas podem dar #errado!

37. Use unchecked exception
Aquelas que herdam
de RuntimeException.
Lembra?

38. Não retorne null
Lance uma exception
Lance um objeto SPECIAL CASE

39. Testes

40. O código de teste...
Limpo com nomes significativos.
Evolução, mas sem #porcaria.
Produção fica #flexível.

41. Os códigos de testes são tão
importantes quanto o código
de produção. Não é um
componente secundário.

42. Classes

43. 1.Classes devem ser pequenas.
2.Devem ser menores ainda!!!!
Como medir o tamanho de uma classe?

44. RESPONSABILIDADE!

45. Cliente
cliente.AvaliarSePodePromoverParaPremium
AvaliadorDeClientePremium
avaliarSePodePromoverParaPremium(cliente)

46. Sistema

47. Injeção de Dependência

48. Desenvolvimento gradual

49. Esta fedendo, troque!

50. Obrigado!
:)