1. What about Clean Code?
Marcelo Santos - @marcelsud
http://marcelosantos.com

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

3. Consequências de código ruim
●
●
●
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
...

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
Onde?
Como?
●
● Pronunciáveis
Que revele seu propósito
● 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. Classes
LoD: Law of Demeter
Design by Contract
Design Patterns
Orthogonality
Cohesion
SOLID

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
http://marcelosantos.com