O documento discute princípios de programação limpa e boas práticas, incluindo: (1) usar nomes significativos e distintos, (2) manter funções pequenas e focadas, (3) evitar repetição de código, e (4) usar objetos de forma eficiente para melhorar o desempenho. O objetivo é produzir código que seja fácil de ler, modificar e depurar.

1. Refinamento e boas práticas de
programação
Luiz Artur Botelho da Silva – labotelho@gmail.com
Pós-gradução Engenharia de Software - FBV
Engenheiro de Sistemas – C.E.S.A.R

2. Agenda
 Código Limpo;
 Como transformar um código ruim em
um bom;
 Programação Geral;

3. Código Limpo

4. Qual o melhor caminho?

5. Dificuldades de se ter um
código limpo
1. Prazos apertados;
2. Pressa para lançar o produto no
mercado;
3. Cronograma extenso.
“Uma bagunça que funciona é melhor
do que nada.” (Robert C. Martin)

6. Custo de ter um código
confuso

7. Solução para produtividade:
Lei de Brooks: "Incluir mais gente em
um projeto atrasado vai atrasá-lo ainda
mais"

8. O que é código limpo?
“Um código limpo é simples e direto. Ele
é tão bem legível quanto uma prosa bem
escrita.“
Fonte: Grady Booch,
Autor do livro: Aplicações com design e análise
orientado a objeto.

9. O que é código limpo?
"Além do seu criador, um
desenvolvedor pode ler e melhorar
um código limpo.“
Fonte: Dave Thomas,
fundador da estratégia Eclipse.

10. Vantagens de ter o código
limpo
1. Simplicidade;
2. Clareza;
3. Flexibilidade;
4. Fácil manutenção;
5. Boa performance;
6. ...

11. Como se aprende a gerar
código limpo?
Não há uma metodologia especifica.
Solução:
1. Ler vários livros;
2. Aprender com a experiência dos
outros.

12. Como transformar um
código ruim em um
bom

13. Nomes Significativos
 Código Ruim
 Código Bom

14. Nomes Significativos
 Código Ruim
 Código Bom

15. Nomes Significativos
 Código Ruim
Sugestão: Usar
fontes distintas com
propósito de realçar
mais as diferenças.

16. Nomes Significativos
 Código Ruim
Sugestão: Faça
distinção dos nomes.

17. Nomes Significativos
 Código Ruim
 Código Bom

18. Funções
 Devem ser pequenas (no máximo 20
linhas);
 Devem fazer apenas uma coisa por
função;
 Devem ter poucos parâmetros de
entrada;

19. Funções (Vários Parâmetros)
 Código Ruim
 Código Bom

20. Funções
 Prefira exceções a retorno de códigos
de erro;
 Evite repetição de código;
 Manter blocos e indentação (no
máximo em 2 níveis);

21. Construtores (Vários Parâmetros)
 Uso do padrão construtor telescópio;
 Uso do padrão javaBeans;
 Uso de objeto criador;

22. Construtores (Vários Parâmetros)
 Código Ruim
Criando uma instância da classe acima:

23. Uso do padrão construtor
telescópio
 Código Bom
Criando uma instância da classe acima:

24. Desvantagens
 O leitor é tentado a entender todos os
parâmetros;
 Longa seqüência de parâmetros
digitadas pode causar erros;

25. Uso do padrão javaBeans
 Código Bom
Criando uma instância da classe acima:

26. Desvantagens
 Um javaBean pode iniciar já em um
estado inconsistente;
 O padrão javaBean impossibilita que
uma classe seja imutável;

27. Uso de objeto criador
 Código Bom

28. Uso de objeto criador
 Criando uma instância default de um objeto criador:
 Criando uma instância setando parâmetros opcionais em
um objeto criador:

29. Uso de objeto criador
 Garante a consistência dos dados
conforme o padrão de construtor
telescópio;
 Garante a legibilidade do padrão
javaBeans;

30. Comentários
 Não usar comentários Javadocs para
métodos privados;
 Evitar comentários excessivos;
 Marcar com comentário ToDo no código
possíveis pontos de modificação;

31. Comentários
 Alertar sobre conseqüências;
 Comentários informativos sobre o
funcionamento da função;
 Evitar comentários redundantes;
 Sempre colocar o comentário junto ao
código que ele descreve;

32. Objetos
 Evite a criação de objetos
desnecessários;
 Prefira primitivas simples a primitivas
encaixotadas;
 Elimine referências de objetos
obsoletas;
 Evite finalizadores;

33. Evite a criação de objetos
desnecessários;
 Código Ruim
 Código Bom

34. Evite a criação de objetos
desnecessários;
 Código Ruim  Código Bom

35. Evite a criação de objetos
desnecessários;
 Vantagens:
1. Reutilização do objeto em outros
pontos do código;
2. Reutilizar um objeto é mais rápido
que criar um novo;
 Desvantagem:
1. Objeto pode nunca está pronto para
ser coletado;

36. Diferença entre primitivas
simples e encaixotadas
 Primitivas simples:  Primitivas encaixotadas:
1. Possui apenas os 1. Possui identidade e seus
seus valores; valores, ou seja, 2
2. Mas eficiente; instancias desse tipo
3. Possui apenas podem ter o mesmo valor
valores funcionais; com instancias diferentes;
Ex.: int i = 2; 2. Menos eficiente;
3. Pode ter tanto valores
funcionais quanto não
funcionais;
Ex.: Integer i = 2; OU
Integer i = null;

37. Prefira primitivas simples a
primitivas encaixotadas
 O que acontece com a saída desse
código?

38. Prefira primitivas simples a
primitivas encaixotadas
 Código Ruim
 Código Bom

39. Quem é mais rápido?
 Código Ruim
 Código Bom

40. Resposta:
 Mudar Long para long na declaração de
sum reduz o tempo de execução de 43
segundos para 6,8 segundos.
Máquina AMD Opteron
170 dual-core de 2,2
GHz e 2 GB de RAM

41. Elimine referências de
objetos obsoletas
 Código Ruim

42. Elimine referências de
objetos obsoletas
 Código Bom

43. Atenção!
 Problemas de OutOfMemoryError
podem ser provocados caso não se
elimine as referências obsoletas;

44. Evite finalizadores
 Código Ruim

45. Evite finalizadores
 Finalizadores são imprevisíveis e com
isso não se sabe a hora que eles
serão executados;
 Finalizadores provocam perda de
desempenho;

46. Evite finalizadores
Conclusão: A inclusão de um
finalizador aumenta o tempo para
2400 ns, deixando o processo de
criação e destruição de objetos
430 vezes mais lento.
Máquina AMD Opteron
170 dual-core de 2,2
GHz e 2 GB de RAM

47. Programação Geral

48. Programação Geral
 Reduza o escopo de variáveis locais,
ou seja, declare ela apenas onde for
usada;
 Prefira loops for a loops while;

49. Programação Geral
 Evite float e double a respostas
exatas;
 Cuidado com o desempenho da
concatenação de strings;

50. Prefira loops for a loops
while
 Código Ruim

51. Prefira loops for a loops
while
 Com loop “for” não há motivo para o uso de
nomes de variáveis diferentes nos dois
loops;
 A variável alocada no loop “for” é liberada
logo após terminar o seu delimitador de
escopo;
 Obs.: Tanto o loop “for” quanto o loop
“while” apresentam o mesmo desempenho.
Fonte: http://stackoverflow.com/questions/1165457/java-for-loop-vs-while-loop-performance-difference

52. Prefira loops for a loops
while
Usando o comando “javap” podemos ver que os 2 loops
são convertidos para o mesmo código interpretado pela
JVM.

53. Cuidado com o desempenho
da concatenação de strings
 Código Ruim

54. Cuidado com o desempenho
da concatenação de strings
 Código Bom

55. Dúvidas

56. Referências Bibliográficas
 ROBERT C. MARTIN.
Código Limpo:
habilidades práticas do
Agile Software, Alta
Books, 2011.

57. Referências Bibliográficas
 Joshua Bloch. Java
Efetivo, 2ª Edição, Alta
Books 2010.