O documento fornece diretrizes para escrever código limpo, discutindo tópicos como: 1) Nomes significativos para variáveis, funções e classes; 2) Funções pequenas que fazem uma única coisa; 3) Tratamento de exceções ao invés de códigos de erro.

1. CLEAN CODE
escrevendo código limpo

2. DISCLAIMER

3. OVERVIEW

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. SOBRE O QUE NÃO FALAREI
• dependency injection • emergência
• TDD • concorrência
• refactoring • frameworks de teste

6. fonte: http://www.osnews.com/story/19266/WTFs_m

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. “NÃO SOU UM EXCELENTE DESENVOLVEDOR. SOU APENAS
UM DESENVOLVEDOR MEDIANO QUE SEGUE À RISCA AS BOAS
PRÁTICAS DE UM CÓDIGO LIMPO.”
(um dev muito famoso)

9. NOMES SIGNIFICATIVOS

10. NOMES SIGNIFICATIVOS
Se o nome requer um
comentário, é um nome
ruim

11. USEM NOMES QUE REVELEM A INTENÇÃO

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. USEM NOMES PRONUNCIÁVEIS

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. USEM NOMES BUSCÁVEIS

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. TAMBÉM NOMEAMOS CLASSES E MÉTODOS

18. NOMES SIGNIFICATIVOS
CLASSES
em geral, classes devem ser representadas por substantivos, não verbos.
bons exemplos: Cliente, Perfil, Estoque, etc.
MÉTODOS
em geral, métodos devem ser representadas por verbos ou frases verbais
bons exemplos: enviarPagamento, removerPagina, salvar, etc. (prefira o infinitivo)

19. NÃO SEJA PIADISTA :)

20. FUNÇÕES

21. SEJA PEQUENO

22. FUNÇÕES
• menos é sempre mais!
• extraia trechos em métodos privados
• lembre-se dos nomes significativos ;)
• vá direto ao ponto

23. FUNÇÕES

24. FAÇA UMA ÚNICA COISA
blocos e endentação,
indicios de que está
fazendo muita coisa

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. LEIA O CÓDIGO DE CIMA PARA BAIXO
Como uma narrativa

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. FUNÇÕES E SEUS ARGUMENTOS

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. FUNÇÕES

31. EVITE OS SIDE EFFECTS

32. FUNÇÕES Onde está o side effect?

33. EXCEÇÕES SÃO MELHORES QUE CÓDIGOS DE ERRO

34. FUNÇÕES

35. DRY (DON’T REPEAT YOURSELF)

36. COMENTÁRIOS
devem valer os bytes que
consomem

37. COMENTÁRIOS NÃO AJUDAM UM CÓDIGO SUJO

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. COMENTÁRIOS ACEITÁVEIS

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. COMENTÁRIOS RUINS

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. COMENTÁRIOS

44. FORMATAÇÃO
pode ser interpretado
como uma coisa pessoal.
apesar disso, valem os
padroes entre times

45. O QUE VALE É A REGRA DO TIME

46. MAS EXISTEM ALGUNS PADRÕES DE LINGUAGENS

47. PYTHON: PEP8
explicar o pq da PEP 8, é sempre bom saber qual existem padroes para
sua importância para o padrão da linguagem. nomes de classe, nomes
pessoas que vão ler o python tem um padrão, de modulo, nomes de
codigo, etc. Java tem outro, C++ tem metodos, variaveis,
outro constantes, etc.

48. E JAVASCRIPT?

49. LIMITES HORIZONTAIS
explicar o pq da linha de
limite horizontal.

50. ENDENTAÇÃO, QUEBRA DE LINHAS E TERNÁRIOS

51. E O IDIOMA?
leve em consideracao a
linguagem de dominio. por
exemplo, ficaria
estranho traduizer
“Folião”

52. OBJETOS E ESTRUTRA DE
DADOS

53. ABSTRAÇÃO DE DADOS

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

57. A LEI DE DEMETER

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

59. vagão de trem

60. TRATAMENTO DE ERRO

61. EXCEÇÕES AO INVÉS DE CÓDIGO DE ERRO ;)

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

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

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

66. NÃO RETORNE NULL
- obriga usos de if
- pode disparar
nullpointer
- considere lancar uma
exceção ou retornar um
objeto especial

68. NÃO PASSE NULL
- obriga tratamento de nulo
- tira a legibilidade do código
algumas linguagens até facilitam

69. CLASSES

70. BASICAMENTE AS MESMAS DICAS DE FUNÇÕES ;)

71. PARTIU ALMOÇAR?
:D

72. MUITO OBRIGADO
@gustavocsb