Clean Code

Talk given to my colleagues at Quatix.

Transcript

1. CLEAN CODE escrevendo código limpo
2. DISCLAIMER
   
3. OVERVIEW
   
4. SOBRE O QUE FALAREI • nomenclaturas • funções • classes • formatação • comentários • objetos • estrutura de dados • tratamento de exceções • boundaries • unit testing
5. SOBRE O QUE NÃO FALAREI • dependency injection • TDD • refactoring • emergência • concorrência • frameworks de teste • JUnit
6. fonte: http://www.osnews.com/story/19266/WTFs_m
7. O QUE É UM CÓDIGO LIMPO? • direto ao ponto • mínimas dependências • sem duplicação • fácil manutenção • padrões definidos • de fácil leitura/entendimento • coberto de testes • elegante
8. “NÃO SOU UM EXCELENTE DESENVOLVEDOR. SOU APENAS UM DESENVOLVEDOR MEDIANO QUE SEGUE À RISCA AS BOAS PRÁTICAS DE UM CÓDIGO LIMPO.”
   (um dev muito famoso)
9. NOMES SIGNIFICATIVOS
   !
10. NOMES SIGNIFICATIVOS
11. USEM NOMES QUE REVELEM A INTENÇÃO
    
12. NOMES SIGNIFICATIVOS
13. USEM NOMES PRONUNCIÁVEIS
14. NOMES SIGNIFICATIVOS
15. USEM NOMES BUSCÁVEIS
16. NOMES SIGNIFICATIVOS
17. TAMBÉM NOMEAMOS CLASSES E MÉTODOS
18. NOMES SIGNIFICATIVOS CLASSES MÉTODOS em geral, classes devem ser representadas por substantivos, não verbos. bons exemplos: Cliente, Perfil, Estoque, etc. em geral, métodos devem ser representadas por verbos ou frases verbais bons exemplos: enviarPagamento, removerPagina, salvar, etc. (prefira o infinitivo)
19. NÃO SEJA PIADISTA :)
20. FUNÇÕES
    !
21. SEJA PEQUENO
22. •menos é sempre mais! •extraia trechos em métodos privados •lembre-se dos nomes significativos ;) •vá direto ao ponto FUNÇÕES
23. FUNÇÕES
24. FAÇA UMA ÚNICA COISA
25. •repare a endentação (sim, é assim que escreve ;) •muitos níveis ~= muita responsabilidade •o método deve fazer uma única coisa, e bem! •dá para extrair? está fazendo mais de uma coisa FUNÇÕES
26. LEIA O CÓDIGO DE CIMA PARA BAIXO
27. •seu código deve ser lido como uma narrativa •temos sujeitos, verbos e predicados :) •narrativas são frases com uma ordem coerente •lembre-se disso ao extrair em métodos privados FUNÇÕES
28. FUNÇÕES E SEUS ARGUMENTOS
29. •muitos argumentos ~= code smell •existem algumas regras para qtd de argumentos •argumentos booleanos em geral não são bons •ex: FUNÇÕES
30. FUNÇÕES
31. EVITE OS SIDE EFFECTS
32. FUNÇÕES
33. EXCEÇÕES SÃO MELHORES QUE CÓDIGOS DE ERRO
34. FUNÇÕES
35. DRY (DON’T REPEAT YOURSELF)
36. COMENTÁRIOS
    !
37. COMENTÁRIOS NÃO AJUDAM UM CÓDIGO SUJO
38. •em geral, servem para explicar um código ruim •um bom código é auto-documentado COMENTÁRIOS •extraia para um método que faça o que diz!
39. COMENTÁRIOS ACEITÁVEIS
40. •comentários sobre licença •comentários informativos •necessidade de explicação de intenção (negócio)
 COMENTÁRIOS
41. COMENTÁRIOS RUINS
42. •por falta do que escrever •redundantes •doc em APIs não-públicas •dizendo algo que o próprio código deveria dizer •código comentado :/
 COMENTÁRIOS
43. COMENTÁRIOS
44. FORMATAÇÃO
    !
45. O QUE VALE É A REGRA DO TIME
46. MAS EXISTEM ALGUNS PADRÕES DE LINGUAGENS
47. PYTHON: PEP8
48. E JAVASCRIPT?
49. LIMITES HORIZONTAIS
50. ENDENTAÇÃO, QUEBRA DE LINHAS E TERNÁRIOS
51. E O IDIOMA?
52. OBJETOS E ESTRUTRA DE DADOS
    
53. ABSTRAÇÃO DE DADOS
56. •objetos expõem comportamentos e escondem dados •estruturas de dados expõem seus dados e não têm comportamentos significativos OBJETOS E ESTRUTURAS DE DADOS
57. A LEI DE DEMETER
58. •um método f de uma classe C só conhece: •métodos de C •objetos criados por f •objetos passados como argumentos para f •objetos em variáveis de instância de C OBJETOS E ESTRUTURAS DE DADOS
60. TRATAMENTO DE ERRO
    
61. EXCEÇÕES AO INVÉS DE CÓDIGO DE ERRO ;)
62. TRATAMENTO DE EXCEÇÃO É UMA DAS COISAS QUE UMA FUNÇÃO/MÉTODO FAZ
64. NÃO USE EXCEÇÕES GENÉRICAS
65. VOCÊ TAMBÉM PODE CRIAR EXCEÇÕES!
66. NÃO RETORNE NULL
68. NÃO PASSE NULL
69. CLASSES
    !
70. BASICAMENTE AS MESMAS DICAS DE FUNÇÕES ;)
71. PARTIU ALMOÇAR?
    ! :D
72. MUITO OBRIGADO @gustavocsb