Clean Code - Como não escrever um código digno de "WTF?!"

Clean Code - Como não escrever um código digno de "WTF?!"

Dd958da4c68b7d3227b3f1cd92a429a6?s=128

Jean Pimentel

November 28, 2017
Tweet

Transcript

  1. Clean Code Como não escrever um código digno de "WTF?!"

  2. Product Engineer @ CI&T Leitor de ficção científica Organizador e

    apoiador do Android BH e CocoaTalks BH Jean Pimentel
  3. Clean Code - Robert C. Martin

  4. O que é um bom código? • Bem escrito •

    Legível • Fácil manutenção
  5. None
  6. Escrever um bom código é pré-requisito para chamar-se de profissional.

    Não há desculpas para fazer nada menos do que o seu melhor.
  7. "Não tenho tempo para isso, preciso fazer o que o

    meu gerente diz, senão serei demitido." Muitos gerentes querem um bom código, mas o trabalho deles é defender os requisitos e cronogramas. Defender um bom código faz parte do seu trabalho! Atitude
  8. "Deixe a área do acampamento mais limpa do que a

    encontrou." Viu algo que pode ser melhorado? Melhore! Regra dos Escoteiros
  9. Nomes

  10. Nomes "There are only two hard things in Computer Science:

    cache invalidation and naming things." Phil Karlton
  11. Nomes Revele o próposito O nome de uma variável, função

    ou classe, deve responder todas as grandes questões. Deve dizer porque ela existe, o que faz e como é usada. // intervalo em dias var d: Int = 0 var intervaloEmDias: Int = 0
  12. Nomes Evite desinformação Evite palavras com outros significados. Trabalhando com

    trigonometria, por exemplo, não utilize hp como abreviação para hipotenusa. Evite atrelar a estrutura de dados aos nomes. Não se refira à um grupo de User como usersList.
  13. Nomes Evite não informação Evite nomes que não forneçam nenhuma

    pista sobre a intenção do autor. func check(c: Any, p: String) -> Bool
  14. Nomes Evite palavras irrelevantes class Product class ProductData class ProductInfo

  15. Nomes Use nomes pronunciáveis Se você não consegue pronunciar, não

    conseguirá discutir o código. "Aí, após chamar a função gtrsfr, o valor é armazenado na variável rs2v"
  16. Nomes Use nomes que facilitem a localização Nomes curtos e

    constantes numéricas são difíceis de localizar no código. let numberOfRetries = 3 Pesquisar por numberOfRetries é muito melhor que pesquisar pelo número 3.
  17. Nomes Escolha uma só palavra por conceito É confuso ter

    fetch, load, get, retrieve com conceitos equivalentes em diversas partes do código. O mesmo se aplica para save e persist.
  18. Comentários

  19. Comentários "Do not comment bad code, rewrite it." Brian Kernighan,

    P.J. Plauger
  20. Comentários Minimize seu uso O código é a única fonte

    de informação realmente confiável. Pense muito bem antes de utilizar comentários. Código cheio de comentários não deveria ser motivo de orgulho.
  21. Comentários Explique as intenções Caso necessário, explique as regras de

    negócio, o motivo daquela abordagem e não o que ele faz.
  22. Formatação

  23. Formatação Não deve ser ignorada A formatação de código trata

    a comunicação, e a comunicação é essencial.
  24. Formatação Respeite a indentação Indentação ruim torna a leitura confusa.

    É cansativo ficar verificando se um trecho do código pertence ou não à um bloco. Configure seu editor para espaços ou tabs corretamente, de acordo com o padrão escolhido pela equipe ou linguagem.
  25. Formatação Mantenha a consistência Escolha um conjunto de regras para

    formatar o código, e aplique-as.
  26. Formatação Não ultrapasse o limite de 500 linhas por arquivo

    Embora esta não deva ser uma regra rígida, é altamente desejável uma quantidade pequena de linhas. Arquivos menores são mais fáceis de ler e entender.
  27. Formatação Separe os conceitos verticalmente Cada linha representa uma expressão

    ou cláusula e cada grupo de linhas representa um pensamento completo. Para facilitar a leitura, esses pensamentos devem ser separados por linhas em branco.
  28. Formatação Use espaços para associar/desassociar elementos relacionados, facilitando a leitura

    let determinant = b * b - 4 * a * c return (-b+sqrt(determinant))/(2*a) let determinant = b*b - 4*a*c; return (-b + sqrt(determinant)) / (2*a)
  29. Formatação Não alinhe colunas Causa problemas no versionamento do código

    private let name: String = "Jean" private let age: Int = 30 public let publicEmail: Email = Email("...")
  30. Formatação Callers devem vir antes dos called sempre que possível

    Isso gera uma leitura natural, evita que a leitura seja saltada entre vários pontos do código. func isFormValid() -> Bool {} func isEmailValid() -> Bool {} func showError() -> Bool {}
  31. Funções

  32. Funções Regras: 1. Devem ser pequenas

  33. Funções Regras: 1. Devem ser pequenas 2. Devem ser ainda

    menores
  34. Funções Regras:

  35. Funções Regras: 1. Devem fazer uma única coisa 2. Devem

    fazê-la corretamente 3. Devem fazer somente isso
  36. Funções Não use argumentos booleanos Passar booleanos indica claramente que

    a função não faz apenas uma coisa. func getBooks(onlyPremium: Bool) -> [Book] func getAllBooks() -> [Book] func getPremiumBooks() -> [Book]
  37. Funções Apenas um nível de indentação Muitos níveis de indentação

    aumentam o tamanho das funções e as tornam mais difíceis de ler e entender, devido aos fluxos alternativos.
  38. Funções Não misture níveis distintos de abstração func shareText() {

    var shareText = getShareText() shareText.replacingOccurrences(of: "##NAME##", with: name) if let image = UIImage(named: "myImage") { let vc = UIActivityViewController(activityItems: ...) presentViewController(vc, ...) } }
  39. Funções Não produza efeitos colaterais Não faça nada de modo

    oculto, alterando atributos que possam produzir resultados inesperados. func verifyLogin(user: User) -> Bool { if !user.isValid() { return false } user.isLogged = true return true; }
  40. Funções O número ideal de parâmetros é ZERO Um ou

    dois parâmetros são aceitáveis. Quanto maior a quantidade, mais difícil será seu teste e maior a carga mental necessária durante a escrita do código.
  41. Funções Use objetos/structs como parâmetros Muitos argumentos é um indicativo

    que estes possam ser envolvidos em uma estrutura própria. func makeCircle(x: Double, y: Double, radius: Double) func makeCircle(center: Point, radius: Double)
  42. Funções Não retorne NULL Quando uma função retorna null, cria

    responsabilidades extras para quem efetuou a chamada. Utilize SPECIAL CASE nesses cenários.
  43. Funções Retorne erros ao invés de códigos de erro Assim

    como o NULL, também adiciona responsabilidades extras à quem faz a chamada à função.
  44. Testes

  45. Testes Seus códigos de teste devem ser tratados igualmente São

    tão importantes quanto o código e ter testes ruins equivale a não ter testes. À medida que o código evoluir, testes antigos irão falhar e quanto pior o código, mais difícil será sua modificação.
  46. Dúvidas?

  47. contato@jeanpimentel.com.br speakerdeck.com/jeanpimentel Contato