1. O documento discute boas práticas de programação como nomes significativos, pequenas funções, tratamento de exceções e testes de unidade. 2. É recomendado usar nomes que revelem o propósito das variáveis e funções, evitar comentários que podem desatualizar e funções devem fazer uma única tarefa. 3. Testes de unidade garantem código limpo e flexível, fornecendo feedback rápido e maior produtividade.

2. Agenda
● Motivação
● Nomes significativos
● Funções
● Comentários
● Formatação
● Tratamento de exceção
● Testes de unidade

3. Era uma vez em 1980...

4. ● Maiores intervalos entre lançamentos
● Bugs não eram corrigidos
● Cada vez mais travamentos

6. Alguns anos depois...

9. O custo de ter um código confuso

10. Por que não fazer de novo?
Afinal somos melhores do
que quando começamos

11. Sem comentários

18. Escolhendo nomes significativos

19. Um bom nome precisa responder 3 perguntas:
1. Por que existe?
2. O que faz?
3. Como é usado?

20. Use nomes que revelem seu proposito

21. Cuidado para não passar informações erradas!

22. Evite nomes sem significado

24. Outro exemplo

26. Use palavras pronunciáveis

27. Notação Húngara

28. Notação Húngara

29. Funções

30. Funções devem ser:
● Pequenas
● Fazer apenas uma coisa
● Ser bem nomeadas
● Devem ser lidas de cima para baixo
● Extrair trechos para funções menores
● DRY

31. Cuidado com a quantidade de parâmetros
Qual é a
quantidade ideal
de parâmetros?
ZERO

32. Mônades
● Geralmente perguntam ou transformam algo
● Evitar retornos void
● Evitar parâmetros lógicos

33. Díades
● Sempre tentar transformá-la em mônade
● Parâmetros deve fazer parte do mesmo
valor
● Cuidar a ordem dos parâmetros

34. Tríades
Problemas:
+ pausa
+ ignoração
+ dificuldade de manter a ordem

35. Comentários

36. Comentários geralmente:
● Mentem
● Desatualizam
● Imprecisos
Porque o código muda!
Porque o código muda!
Porque o código muda!

37. Uso de comentários
● Esclarecimento
● Alerta de consequência
● JavaDoc em API pública
● Comentário legal
● TODO
● Redundantes
● Longos
● HTML
● Explicando código
● Ao lados de cada chave
● JavaDoc em API NÃO
pública
● Código comentado

38. Formatação

39. Alguns cuidados:
● Manter o código bem identado
● Distância vertical
● Função dependente
● Linha de no máximo 120 caracteres
● Classes devem tem o minimo de linhas
possível

40. Tratamento de exceções

41. Exceções
● Usar exceções em vez de retornar código de erro
● Não pode obscurecer a lógica
● Criar testes que forcem a exceção
● Use exceções não verificadas
● Lance exceções com um contexto

42. Não retorne NULL

43. Não retorne NULL
Diminui o número de NullPointerException

44. Não passe NULL

45. Testes de Unidade

47. As 3 leis do TDD
● Você não pode escrever código de produção a menos que ele
tenha um teste de unidade que falha.
● Você não pode escrever mais teste de unidade que o suficiente
para falhar; e erros de compilação são falhas.
● Você não pode escrever mais que o suficiente, para o código de
produção passar em um teste de unidade.

48. Vantagens
● flexibilidade
● código limpo
● passível de mudanças
● feedback
● segurança
● maior produtividade

49. Testes = Código

50. Classes

51. Como elas devem ser?
● Possuir nomes descritivos
● Pequenas
● SRP
● Alta coesão

52. O que é SRP?

53. O que é alta coesão?