Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Jean Pimentel

November 28, 2017
Tweet

More Decks by Jean Pimentel

Other Decks in Programming

Transcript

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

    View full-size slide

  2. Product Engineer @ CI&T
    Leitor de ficção científica
    Organizador e apoiador do
    Android BH e CocoaTalks BH
    Jean Pimentel

    View full-size slide

  3. Clean Code - Robert C. Martin

    View full-size slide

  4. O que é um bom código?
    ● Bem escrito
    ● Legível
    ● Fácil manutenção

    View full-size slide

  5. 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.

    View full-size slide

  6. "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

    View full-size slide

  7. "Deixe a área do acampamento mais limpa do que a encontrou."
    Viu algo que pode ser melhorado? Melhore!
    Regra dos Escoteiros

    View full-size slide

  8. Nomes
    "There are only two hard things in Computer
    Science: cache invalidation and naming things."
    Phil Karlton

    View full-size slide

  9. 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

    View full-size slide

  10. 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.

    View full-size slide

  11. 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

    View full-size slide

  12. Nomes
    Evite palavras irrelevantes
    class Product
    class ProductData
    class ProductInfo

    View full-size slide

  13. 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"

    View full-size slide

  14. 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.

    View full-size slide

  15. 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.

    View full-size slide

  16. Comentários

    View full-size slide

  17. Comentários
    "Do not comment bad code, rewrite it."
    Brian Kernighan, P.J. Plauger

    View full-size slide

  18. 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.

    View full-size slide

  19. 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.

    View full-size slide

  20. Formatação

    View full-size slide

  21. Formatação
    Não deve ser ignorada
    A formatação de código trata a comunicação, e a comunicação
    é essencial.

    View full-size slide

  22. 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.

    View full-size slide

  23. Formatação
    Mantenha a consistência
    Escolha um conjunto de regras para formatar o código, e
    aplique-as.

    View full-size slide

  24. 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.

    View full-size slide

  25. 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.

    View full-size slide

  26. 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)

    View full-size slide

  27. 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("...")

    View full-size slide

  28. 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 {}

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. Funções
    Regras:

    View full-size slide

  32. Funções
    Regras:
    1. Devem fazer uma única coisa
    2. Devem fazê-la corretamente
    3. Devem fazer somente isso

    View full-size slide

  33. 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]

    View full-size slide

  34. 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.

    View full-size slide

  35. 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, ...)
    }
    }

    View full-size slide

  36. 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;
    }

    View full-size slide

  37. 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.

    View full-size slide

  38. 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)

    View full-size slide

  39. 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.

    View full-size slide

  40. 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.

    View full-size slide

  41. 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.

    View full-size slide

  42. [email protected]
    speakerdeck.com/jeanpimentel
    Contato

    View full-size slide