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