$30 off During Our Annual Pro Sale. View Details »

Clean Code - Como não escrever um código digno ...

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. Product Engineer @ CI&T Leitor de ficção científica Organizador e

    apoiador do Android BH e CocoaTalks BH Jean Pimentel
  2. O que é um bom código? • Bem escrito •

    Legível • Fácil manutenção
  3. 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.
  4. "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
  5. "Deixe a área do acampamento mais limpa do que a

    encontrou." Viu algo que pode ser melhorado? Melhore! Regra dos Escoteiros
  6. Nomes "There are only two hard things in Computer Science:

    cache invalidation and naming things." Phil Karlton
  7. 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
  8. 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.
  9. 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
  10. 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"
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. Formatação Não deve ser ignorada A formatação de código trata

    a comunicação, e a comunicação é essencial.
  16. 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.
  17. 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.
  18. 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.
  19. 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)
  20. 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("...")
  21. 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 {}
  22. Funções Regras: 1. Devem fazer uma única coisa 2. Devem

    fazê-la corretamente 3. Devem fazer somente isso
  23. 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]
  24. 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.
  25. 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, ...) } }
  26. 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; }
  27. 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.
  28. 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)
  29. 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.
  30. 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.
  31. 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.