Código limpo é essencial para manter a produtividade e reduzir custos. Princípios como nomes significativos, poucos parâmetros, eliminação de duplicação e comentários, e uso de padrões como SOLID ajudam a produzir código de melhor qualidade e mais fácil de manter. Testes automatizados também são importantes para evitar regressões.

1. What about Clean Code?
Marcelo Santos - @marcelsud

2. What about Clean Code?
“It is not enough for code to work.”
Robert C. Martin (Uncle Bob)

3. ● Código duplicado
● Classes longas (se houver)
● Parâmetros demais
● Falta de testes (ou nenhum)
● Falta de Coding Standards
● No design patterns at all
● Código morto
● Alta curva de aprendizado
● Uma alteração, vários bugs
● Alocação de mais recursos
● Elevado custo em manutenção
● Queda de produtividade
● Perda de performance
● Remendos / Gambiarras
● ...
Consequências de código ruim

4. A Regra do Escoteiro
“Deixe a área do acampamento mais limpa do que
como você a encontrou”
Boy Scouts of America

8. Nomes significativos
Como?
● Pronunciáveis
● Que revele seu propósito
Onde?
● Variáveis
● Métodos
● Parâmetros
● Classes
● Namespaces
● etc

9. Nomes ruins

10. Nomes melhores

11. Parâmetros demais
Os métodos devem ter um número pequeno de parâmetros.
Nenhum é o ideal.
Acima de três é questionável.

12. Parâmetros demais

13. Poucos parâmetros

14. Comentários

15. Comentários
"Não insira comentários num código ruim, reescreva-o"
Brian W. Kernighan e P. J. Plaugher

16. Não faça isso…

17. Lembre-se...
Se você precisa esclarecer seu código com um
comentário, talvez seja um bom momento para
revê-lo.

18. Duplicação
DRY: Don’t Repeat Yourself
Sempre que você vir duplicação em código, isso significa que
você perdeu uma chance para abstração.
Encontre e elimine duplicações sempre que puder!

19. Código morto
● Variáveis não utilizadas
● Pedaços de código inúteis
● Comentários que não acrescentam informações
Faça a coisa certa: Dê a eles um funeral decente!

20. Flag Arguments
“Argumentos Booleanos claramente declaram que o
método possui mais que uma responsabilidade. Eles
são confusos e devem ser eliminados.”
Uncle Bob

21. Flag Arguments

22. Flag Arguments

23. Encapsular condicionais
melhor que...

24. Substituir números mágicos por constantes
melhor que...

25. Evitar condicionais negativas
melhor que...

26. Coding Standards
“Softwares são feitos para ser lidos por humanos, e somente
incidentemente para ser executados por computadores”
H. Abelson and G. Sussman

27. Tratamento de erros
● Evitar retornar um código de erro
● Lançar excessões com contexto
● Não retornar NULL
● Utilizar mensagens informativas

28. Testes unitários
Fast: Devem ser rápidos.
Independent: Sem depender uns dos outros e na hora que desejar.
Repeatable: Devem passar tanto no servidor, quanto num notebook sem wi-fi.
Self-validating: Devem garantir o resultado sem intervenção manual.
Timely: Devem ser criados antes do código.

29. LoD: Law of Demeter
Design by Contract
Design Patterns
Orthogonality
Cohesion
SOLID
Classes

30. SOLID
SRP: Single responsibility principle
a class should have only a single responsibility.
OCP: Open/closed principle
“software entities … should be open for extension, but closed for modification”.
LSP: Liskov substitution principle
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”
ISP: Interface segregation principle
“many client-specific interfaces are better than one general-purpose interface.”
DIP: Dependency inversion principle
one should “Depend upon Abstractions. Do not depend upon concretions.”

31. Classes
KISS: Keep it simple, stupid!
"A perfeição é alcançada não quando não há mais nada para adicionar,
mas quando não há mais nada que se possa retirar"
Antoine de Saint-Exupéry, autor de "O Pequeno Príncipe"
Toda complexidade desnecessária deve ser descartada.

32. What about Clean Code?
Marcelo Santos - @marcelsud