O documento discute os princípios de código limpo e bonito, enfatizando a importância de nomes significativos, métodos curtos com uma única responsabilidade, classes coesas e abstrações. Também aborda boas práticas como encapsulamento, tratamento de erros e arquitetura limpa.

1. Mauricio Aniche
mauricio.aniche@caelum.com.br
@mauricioaniche
http://www.aniche.com.br

3. O que é “bonito”?

4. Qual é o mais bonito?

5. Qual é o mais bonito?

6. Qual é o mais bonito?

7. simples?
?
flexível?fácil de
ler? sem
duplicações?curto?
enxuto?
O que é código bonito?

8. Qual é o menos feio?

9. É mais fácil identificar
o feio! :)
! :)E isso pode ser útil!

10. métodos
longos
sem
padrão
classes
gigantes
código
repetidomuitos
parâmetros
muitos
if’s

11. “As feias que
me perdoem,
mas beleza é
fundamental!”
”

12. Agora vai ficar técnico!

13. Pensar nos nomes
é importante!
é importante!
Deve dizer o que ele faz,
e como deve ser usado!
Tira a necessidade de ler
a implementação do método.
Deve ser fácil de ser entendido
por todos da equipe.

14. int kkk; // dias da semana
WTF?
Use nomes que
façam sentido!
façam sentido!

15. public List<int[]> getThem() { List<int[]> list1
= new ArrayList<int[]>(); for (int[] x :
theList) if(x[0] == 4) list1.add(x);
return list1;}
public List<int[]> getFlaggedCells()
{ List<int[]> flaggedCells = new
ArrayList<int[]>(); for (int[] cell : gameBoard)
if(cell.isFlagged())
flaggedCells.add(cell); return flaggedCells;}

16. for(int i = 0; ...) {
int a1 = i * 8;
int a2 = a1 / 2;
int a3 = (a1 + a2) * 3;
}
Não crie variáveis
com nomes similares!

17. List<Conta> contasAbertas;
@Test
public void deve_testar_x(){}
Tenha um padrão!

18. List<Conta> scherobles;
Pense na língua que vai
escrever.
Use nomes
pronunciáveis!

19. E em relação aos
métodos?!
?!
Deve ser enxuto.
Deve ter apenas uma
responsabilidade.
Deve deixar claro sua intenção.

20. Quantas linhas? 20? 100?
Uma página de impressora?
Uma tela?
Tamanho dos
métodos
métodos

21. Qual o tamanho máximo?
4? 8? 20?
2 ifs? 3 ifs?
Complexidade
Ciclomática
Ciclomática

22. Ou o método faz alguma coisa,
ou ele devolve alguma coisa.
Nunca os dois.
Command Query
Separation
Separation

23. O menor possível.
Mais que 3? Pense pra fazer
isso.
Quantidade de
parâmetros?

24. Evite passar “boolean” pros
seus métodos.
Método faz coisa demais?
Usar flags?

25. Evite retornar null.
A ideia do bom vizinho.
Não retorne null!

26. Evite repetir código.
- Extraia o que há de comum
para outros métodos.
Código repetido?

27. Comentário de código
Somente quando necessário.
O comentário não é “código”!
Raramente são atualizados.

28. Comentário não é “maquiagem”
de código.
- Código está feio, refatora.
Código feio precisa
de comentário?

29. if(aluno.getQtdCursos()>10 &&
aluno.getMeses() > 24) {
// ...
}
E aquela condição
complicada?
complicada?
if(aluno.isImportante()) {
// ...
}

30. O melhor é não ter.
- Explicar algoritmo
matemático?
-Explicar alguma decisão de
negócio?
Quando um
comentário é bom?

31. E minhas classes?
Devem ter uma única
responsabilidade.
Quanto mais enxuta,
mais fácil de manter e
reutilizar.
Não deve depender
de muitas outras classes.

32. Objetos devem ter atributos e
métodos que manipulam esses
atributos.
Isso é diferente de uma
simples estrutura de dados.
OO from the
Trenches

33. Pense em abstrações.
Abstrações possibilitam a
evolução mais natural do
código.
Estude padrões de projeto.
Abstrações são
do bem
do bem

34. A classe deve esconder COMO
ela faz sua tarefa.
Intimidade inapropriada.
Encapsule direito!

35. Quando bem utilizados, ajudam
a flexibilizar o sistema.
“Todo mundo” conhece a
solução.
Estude padrões de
projeto

36. Tratamento de erros
Deve ser feito de maneira elegante.
Use exceções para
casos excepcionais.

37. Não use o retorno do método
para indicar se houve uma
exceção.
Não use o retorno
do método!

38. Dê contexto para sua exceção.
Se você está encapsulando a
exceção, passe-a como a
“causa” da sua exceção.
Exceptions
caprichadas

39. Arquitetura?
Arquitetura vira código...

40. Não saia criando EJBs pra lá
e pra cá...
Não tenha 200 camadas, só
porque fica bonito no
diagrama.
Evite arquiteturas
complicadas demais
complicadas demais

41. Não me diga que o Spring
MVC / VRaptor não serve pra
você...
Esqueça o seu framework
corporativo caseiro!

42. Não escreva regras de negócio
no controller.
MVC é legal!
Controllers na Web

43. O que os “pops” de lá
dizem?
Clean code is simple and direct. Clean code reads like
wellwritten prose. (Grady Booch)
Clean code always looks it was written by someone
who cares. There is nothing obvious that you can do to
make it better. (Michael Feathers)
Clean code can be read, and enhanced by a developer
other than its original author. (Dave Thomas)

44. O que os “pops” daqui
dizem?
Código bom é o código que com o mínimo de esforço
um desenvolvedor mediano do projeto entende mesmo
após o criador sair do projeto. (Guilherme Silveira)
Código bonito é código fácil e bom de ler. (Paulo Silveira)
Código que você consegue ler imediatamente,
sem precisar se esforçar. (Lucas Cavalcanti)

45. O que os “pops” daqui
dizem?
Código feito pra pessoas lerem: tão simples quanto
possível, bem separado, com nomes decentes, etc.
(Cecília Fernandes)
Código bonito é código cujos passos estão todos em um
mesmo nível de abstração de forma que eu entenda
claramente o melhor ponto para alterá-lo sem ter que
me preocupar se minha mudança gera impactos
inesperados. (Hugo Corbucci)

46. Referências
• Code Beauty. Fabio Kon. 2010.
• Clean Code. Robert Martin.

47. OBRIGADO!
Mauricio Aniche
mauricio.aniche@caelum.com.br
@mauricioaniche
http://www.aniche.com.br
http://www.tddnomundoreal.com.br