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

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