Baixar para ler offline
Carregado porMarcelo Santos
Clean code
O documento discute princípios de código limpo, incluindo: 1) Nomes significativos para variáveis, métodos e classes; 2) Evitar parâmetros excessivos nos métodos; 3) Comentários não devem ser usados para explicar código ruim, que deve ser reescrito.
Clean code
- 1. What about CleanCode? Marcelo Santos - @marcelsud http://marcelosantos.com
- 2. What about CleanCode? “It is not enough for code to work.” Robert C. Martin (Uncle Bob)
- 3. Consequências de códigoruim ● ● ● 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 doEscoteiro “Deixe a área do acampamento mais limpa do que como você a encontrou” Boy Scouts of America
- 8. Nomes significativos Onde? Como? ● ● Pronunciáveis Querevele seu propósito ● Variáveis ● Métodos ● Parâmetros ● Classes ● Namespaces ● etc
- 9.
- 10.
- 11. Parâmetros demais Os métodosdevem ter um número pequeno de parâmetros. Nenhum é o ideal. Acima de três é questionável.
- 12.
- 13.
- 14.
- 15. Comentários "Não insira comentáriosnum código ruim, reescreva-o" Brian W. Kernighan e P. J. Plaugher
- 16.
- 17. Lembre-se... Se você precisaesclarecer seu código com um comentário, talvez seja um bom momento para revê-lo.
- 18. Duplicação DRY: Don’t RepeatYourself 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áveisnã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 Booleanosclaramente declaram que o método possui mais que uma responsabilidade. Eles são confusos e devem ser eliminados.” Uncle Bob
- 21.
- 22.
- 23.
- 24. Substituir números mágicospor constantes melhor que...
- 25.
- 26. Coding Standards “Softwares sãofeitos 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: Devemser 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 ofDemeter Design by Contract Design Patterns Orthogonality Cohesion SOLID
- 30. SOLID SRP: Single responsibilityprinciple 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 itsimple, 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 CleanCode? Marcelo Santos - @marcelsud http://marcelosantos.com