Clean code

1,192 views
1,117 views

Published on

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,192
On SlideShare
0
From Embeds
0
Number of Embeds
61
Actions
Shares
0
Downloads
42
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Clean code

    1. 1. CLEAN CODE escrevendo código limpo
    2. 2. DISCLAIMER
    3. 3. OVERVIEW
    4. 4. SOBRE O QUE FALAREI• nomenclaturas • objetos• funções • estrutura de dados• classes • tratamento de exceções• formatação • boundaries• comentários • unit testing
    5. 5. SOBRE O QUE NÃO FALAREI • dependency injection • emergência • TDD • concorrência • refactoring • frameworks de teste
    6. 6. fonte: http://www.osnews.com/story/19266/WTFs_m
    7. 7. O QUE É UM CÓDIGO LIMPO?• direto ao ponto • padrões definidos• mínimas dependências • de fácil leitura/entendimento• sem duplicação • coberto de testes• fácil manutenção • elegante sindrome da janela quebrada
    8. 8. “NÃO SOU UM EXCELENTE DESENVOLVEDOR. SOU APENASUM DESENVOLVEDOR MEDIANO QUE SEGUE À RISCA AS BOAS PRÁTICAS DE UM CÓDIGO LIMPO.” (um dev muito famoso)
    9. 9. NOMES SIGNIFICATIVOS
    10. 10. NOMES SIGNIFICATIVOS Se o nome requer um comentário, é um nome ruim
    11. 11. USEM NOMES QUE REVELEM A INTENÇÃO
    12. 12. NOMES SIGNIFICATIVOS 1. What kinds of things are in theList? 2. What is the significance of the zeroth subscript of an item in theList? 3. What is the significance of the value 4? 4. How would I use the list being returned?
    13. 13. USEM NOMES PRONUNCIÁVEIS
    14. 14. NOMES SIGNIFICATIVOS 1. Parte do nosso cérebro é dedicado ao conceito de palavras. e palavras, por definição, são pronunciaveis; usemos essa parte do cérebro! 2. Programar é uma atividade social. 3. método Dê tê á Érre Cê Dê
    15. 15. USEM NOMES BUSCÁVEIS
    16. 16. NOMES SIGNIFICATIVOS 1. Muito mais facil encontrar WORK_DAYS_PER_WEEK DO QUE “5” 2. “SUM” não é de fato um nome muito útil, mas ao menos já é mais buscável do que simplestemente “s” 3. CODE SMELL! MAGIC NUMBER!
    17. 17. TAMBÉM NOMEAMOS CLASSES E MÉTODOS
    18. 18. NOMES SIGNIFICATIVOSCLASSESem geral, classes devem ser representadas por substantivos, não verbos.bons exemplos: Cliente, Perfil, Estoque, etc.MÉTODOSem geral, métodos devem ser representadas por verbos ou frases verbaisbons exemplos: enviarPagamento, removerPagina, salvar, etc. (prefira o infinitivo)
    19. 19. NÃO SEJA PIADISTA :)
    20. 20. FUNÇÕES
    21. 21. SEJA PEQUENO
    22. 22. FUNÇÕES• menos é sempre mais!• extraia trechos em métodos privados• lembre-se dos nomes significativos ;)• vá direto ao ponto
    23. 23. FUNÇÕES
    24. 24. FAÇA UMA ÚNICA COISAblocos e endentação,indicios de que estáfazendo muita coisa
    25. 25. FUNÇÕES• 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
    26. 26. LEIA O CÓDIGO DE CIMA PARA BAIXOComo uma narrativa
    27. 27. FUNÇÕES• 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
    28. 28. FUNÇÕES E SEUS ARGUMENTOS
    29. 29. FUNÇÕES• muitos argumentos ~= code smell• existem algumas regras para qtd de argumentos• argumentos booleanos em geral não são bons• ex:
    30. 30. FUNÇÕES
    31. 31. EVITE OS SIDE EFFECTS
    32. 32. FUNÇÕES Onde está o side effect?
    33. 33. EXCEÇÕES SÃO MELHORES QUE CÓDIGOS DE ERRO
    34. 34. FUNÇÕES
    35. 35. DRY (DON’T REPEAT YOURSELF)
    36. 36. COMENTÁRIOS devem valer os bytes que consomem
    37. 37. COMENTÁRIOS NÃO AJUDAM UM CÓDIGO SUJO
    38. 38. COMENTÁRIOS “Ooh, I’d better comment that!” No! You’d better clean it!• em geral, servem para explicar um código ruim• um bom código é auto-documentado• extraia para um método que faça o que diz!
    39. 39. COMENTÁRIOS ACEITÁVEIS
    40. 40. COMENTÁRIOS // format matched kk:mm:ss EEE, MMM dd, yyyy Pattern timeMatcher = Pattern.compile( "d*:d*:d* w*, w* d*, d*");• comentários sobre licença• comentários informativos• necessidade de explicação de intenção (negócio)
    41. 41. COMENTÁRIOS RUINS
    42. 42. COMENTÁRIOS // format matched kk:mm:ss EEE, MMM dd, yyyy Pattern timeMatcher = Pattern.compile( "d*:d*:d* w*, w* d*, d*");• 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 :/
    43. 43. COMENTÁRIOS
    44. 44. FORMATAÇÃOpode ser interpretadocomo uma coisa pessoal.apesar disso, valem ospadroes entre times
    45. 45. O QUE VALE É A REGRA DO TIME
    46. 46. MAS EXISTEM ALGUNS PADRÕES DE LINGUAGENS
    47. 47. PYTHON: PEP8explicar o pq da PEP 8, é sempre bom saber qual existem padroes parasua importância para o padrão da linguagem. nomes de classe, nomespessoas que vão ler o python tem um padrão, de modulo, nomes decodigo, etc. Java tem outro, C++ tem metodos, variaveis, outro constantes, etc.
    48. 48. E JAVASCRIPT?
    49. 49. LIMITES HORIZONTAIS explicar o pq da linha de limite horizontal.
    50. 50. ENDENTAÇÃO, QUEBRA DE LINHAS E TERNÁRIOS
    51. 51. E O IDIOMA?leve em consideracao alinguagem de dominio. porexemplo, ficariaestranho traduizer“Folião”
    52. 52. OBJETOS E ESTRUTRA DE DADOS
    53. 53. ABSTRAÇÃO DE DADOS
    54. 54. OBJETOS E ESTRUTURAS DE DADOS• objetos expõem comportamentos e escondem dados• estruturas de dados expõem seus dados e não têm comportamentos significativos
    55. 55. A LEI DE DEMETER
    56. 56. OBJETOS E ESTRUTURAS DE DADOS• 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
    57. 57. vagão de trem
    58. 58. TRATAMENTO DE ERRO
    59. 59. EXCEÇÕES AO INVÉS DE CÓDIGO DE ERRO ;)
    60. 60. TRATAMENTO DE EXCEÇÃO É UMA DAS COISAS QUE UMA FUNÇÃO/MÉTODO FAZ try except finally deve ser o unico bloco de um metodo
    61. 61. NÃO USE EXCEÇÕES GENÉRICAS conheça seu código. saiba que tipos de exceções podem ser disparadas. se nao conhece as exceções default, dê uma lida nelas
    62. 62. VOCÊ TAMBÉM PODE CRIAR EXCEÇÕES! se couber fazer uma exceção especifica, crie uma classe de Excecao sua que será usada em outros pontos do projeto
    63. 63. NÃO RETORNE NULL - obriga usos de if - pode disparar nullpointer - considere lancar uma exceção ou retornar um objeto especial
    64. 64. NÃO PASSE NULL- obriga tratamento de nulo- tira a legibilidade do códigoalgumas linguagens até facilitam
    65. 65. CLASSES
    66. 66. BASICAMENTE AS MESMAS DICAS DE FUNÇÕES ;)
    67. 67. PARTIU ALMOÇAR? :D
    68. 68. MUITO OBRIGADO @gustavocsb

    ×