O documento discute os princípios de código limpo, incluindo: (1) código limpo deve ser eficiente e ter lógica direta para minimizar bugs, (2) deve ter poucas dependências, e (3) deve ser legível para facilitar manutenção. Ele também fornece dicas como usar nomes significativos e formatar código claramente.

1. Rogério Fontes
@rogeriofontes
http://rogeriofontes.inf.br
Arquiteto Java.
Apaixonado em código e formas ágeis de criá-los, Lider do UaiJUG
(Grupo de Usuários do Triângulo Mineiro, Lider Tecnico Everis.
Clean Code

2. Agenda
O que é um código limpo?
O que é um código ruim?
Quanto custa um código ruim?
O que se fala de código limpo?
Como deve ser um código limpo.
Algumas regras para melhorar seu código.
Equipe

3. Tenho um problema para resolver,
mas o tempo está curto. “Bora” resolver?

4. Funciona, mais é viável?

5. Funciona, mais é viável?

6. Ao resolver problemas e entregar solução temos que
pensar na melhor forma de faze-lo, não
simplesmente resolver momentaneamente.

7. Quando vemos um problema ou uma “gambiara”
temos a responsabilidade de arrumar.
Temos que ter em mente a regra do escoteiro.

8. Regra do escoteiro
“Você deve sempre deixar o lugar
mais limpo do que encontrou”

9. Clean code

10. Clean code
O que representa um código limpo:
Eficiencia
Única responsabilidade

11. Clean code
O que representa um código ruim:
Que não é legível a outros programadores
Multiplica o tempo gasto ao codificar.

12. Código ruim
Porque fazemos?
 Estava com pressa?
 Seu chefe cobrando a toda hora (Gerente tele-
sena)?
 Cansado?
 Estressado?
 Cronograma estourado?

13. Código ruim
Código ruim custa caro

14. Voltando ao Limpo.
O que se fala sobre código limpo:

15. Clean coders
• “Código deve ser limpo
e eficiente, como uma
lógica direta, para
minimizar os bug.
Código limpo faz bem
apenas uma coisa”
http://www.stroustrup.com/
• http://pt.wikipedia.org/wiki/Bjarne_Stroustrup
BjarneStroustrup
Criador do C++
• “Deve ser limpo e direto”
• “Deve ser legível quem
uma prosa bem escrita”
• http://pt.wikipedia.org/wi
ki/Grady_Booch
Grady Booch
Autor :
Software Engineeringwith Ada
Object-Oriented Analysis and
Design with Applications
“Ele tem teste unitários e
de aceitação, nomes
significativos; ele oferece
apenas uma maneira de
fazer uma tarefa; e possui
poucas dependências”
http://en.wikipedia.org/wik
i/Dave_Thomas_%28Ame
rican_businessman%29
DaveThomas
Fundador OTI,
e padrinho da estrategia Eclipse

16. Clean coders
• “Parece ter sido escrito
por alguem que se
importa”
• http://www.objectmentor.com
/omTeam/feathers_m.html
• http://en.wikipedia.org/wiki/L
egacy_code
Michael Feaths
Autor:
Working Effectively with LegacyCode
“Efetue todos os testes”
“Sem duplicação de
código”
“Expressa todas as ideias
do projeto que estão no
sistema”
“Minimiza o número de
entidades, como classes,
métodos, e outras do tipo”
http://en.wikipedia.org/wik
i/Ron_Jeffries
Ron Jeffreis
Autor :
Extreme programming installed and
Extreme Programing Adventure in C#
• “Cada rotina que você le
faz o que
• realmente o que você
espera”
http://pt.wikipedia.org/wi
ki/Ward_Cunningham
Ward Cunnigham
Desenvolveu o primeiro wiki.
Pioneiro nos padrões de designe
Extreme Programming.

17. •Robert C.
Martin
(Uncle Bob)
“Escola do pensamento”
Autor:
Clean Code: A Handbook of Agile
Software Craftsmanship
Agile Software Development: Principles,
Patterns and Practices”

18. Evite Mapeamento Mental
O programador leitor não deve traduzir
mentalmente os nomes que você escolheu por
outros que ele conheça.
 Ex: (a1, a2, a3)
Mesmo não gerando confusão o programador
tem que traduzir para saber o qual é o significado.

19. Evite Mapeamento Mental
Há nomes, no universo da escrita de códigos, que
já estão bem integradas pela comunidade de
desenvolvedores, por exemplo:
Variáveis “i” e “j” usadas nas iterações “for”.
Nestes casos, não há motivo para usar “r” ou “x”

20. NOMES QUE REVELAM
O PROPÓSITO
Sempre devemos priorizar um código que revela a
verdadeira intenção e demostrar a intenção real do
que ele vai fazer:
• Int et // tempo decorrido em segundos (início e final da iteração).
• int tempoDecorridoSegundos;
• int tempoInicioFim;

21. Cuidados com Similares
USAR COM CUIDADO AS LETRAS “L”, “I” E “O”.
Elas são facilmente confundidas com os numerais
1 (um) e 0 (zero).

22. NOMES PARECIDOS
Temos que ter cuidado ao usar nomes muito
parecidos pois pode uma má interpretação e
possibilitar ao erro.
• double valorTotalDasRsDoOrcamentoAtual; // receitas
• double valorTotalDasDsDoOrcamentoAtual; // despesas
• double valorTotalDosCsDoOrcamentoAtual; // custos

23. NOMES PARECIDOS
Possível solução:
Class OrcamentoAtual{
public double getTotalDeReceitas(){
return ...
}
public double getTotalDeDespesas(){
return ...
}
public double getTotalDeCustos(){
return ...
}
}

24. FAÇA DISTINÇÕES
SIGNIFICATIVAS
Evite nomes comuns, que não agregam valor ao
seu sentido.
• getActiveAccount()
• getActiveAccounts()
• getActiveAccountInfo()
• getActiveAccountData()
Como os programadores deste projeto poderiam
saber qual método chamar? Faça a distinção dos
nomes de uma maneira que o leitor compreenda
suas diferenças.

25. EVITAR CODIFICAÇÕES
Programadores, codificam demais, convivem com
isso em seu dia-a-dia; mais código só iria trazer
mais problemas, tarefa extra de decifração. Nomes
codificados raramente são impronunciáveis, além
de ser fácil escrevê-los incorretamente.

26. EVITAR CODIFICAÇÕES
Veja o exemplo, que poderia ser um arquivo XML
para exportação:
• end001_Orc_CadCli.xml
• cep002_Rec_CadFor.xml
Tente fazer algo que representa qual é o seu real
objetivo.
• endereco_orcamento_cadatroCliente_001.xml
• cep_receita_cadastroFornecedor_002.xml

27. EVITE INFORMAÇÕES
ERRADAS
Cuidado ao usar nomes muito parecidos, é difícil
perceber a pequena diferença entre :
• XUZControllerForEfficientHanlingOfString em um módulo e
• XUZControllerForEfficientStorageOfString em outro.
Ambos os nomes são muito semelhantes e mais
não fazem a mesma coisa, o que pode confundir
os programadores.

28. USE CONVENÇÕES
Java blueprints:
http://www.oracle.com/technetwork/java/javaee/blueprints/index.html
Pesquise sobre DDD (Domain-Driven Design):
http://domaindrivendesign.org/
Aprenda Bem Orientação a objetos.

29. OBJETOS E ESTRUTURAS DE
DADOS
Siga a Lei de Demeter:
Cada unidade deve ter apenas conhecimento
limitado sobre as outras unidades: Unidades de
apenas "de perto" relacionado com a unidade
atual.
Cada unidade deve apenas conversar com seus
amigos, não falar com estranhos.
Apenas conversar com seus amigos mais
próximos.
http://en.wikipedia.org/wiki/Law_of_Demeter

30. USAR NOMES PRONUNCIÁVEIS
Nomeamos variáveis membro, variáveis locais,
métodos, objetos, ou seja, tudo dentro de nosso
código, é bom que esses nomes sejam bem
escolhidos, pois teremos seguramente longas
discussões com outros programadores, analistas
e usuários finais, é bom que os nomes desses
componentes sejam claros e de fácil pronúncia.
.

31. USAR NOMES PRONUNCIÁVEIS
A esse respeito Martin (2012) ressalta:
“[...] Se não puder pronunciá-lo, não terá como
discutir sobre tal nome sem parecer um idiota. “Bem,
aqui no be cê erre três cê ene tê”, temos um pê esse
zê quê int, viram? Isso importa porque a
programação é uma atividade social”. (MARTIN (1),
2011:22).

32. EVITE INFORMAÇÕES
ERRADAS
Evitem sempre passar informações que não seja
verdadeiras e que torne o codigo sem sentido e
que desvia do que se deseja.
• accountList //um lista de contas
Não se refira a um grupo de contas
como accountList, a menos que realmente seja
um List. A palavra list (Lista) significa algo
específico para programadores.
• accountGroup ou accounts

33. USE NOMES PASSÍVEIS DE
BUSCA
Nomes de uma só letra ou numéricos possuem um
problema em particular por não ser fácil localizá-
los ao longo do texto. O tamanho de um nome
deve ser proporcional ao tamanho do escopo.
Nomes de uma letra só somente deveriam ser
usados em métodos pequenos.

34. USE NOMES PASSÍVEIS DE
BUSCA
Escopos de uma linha ou duas não geram
mapeamento mental.
Se uma variável ou constante pode ser vista ou
usada em vários lugares dentro do código, é
imperativo atribuí-la um nome fácil para busca-lo

35. A NOTAÇÃO HÚNGARA
A notação Húngara visa a facilitar o
reconhecimento do tipo de variável num programa
colocando ao nome um sufixo descrevendo seu
tipo.
• Exemplo: S ao invês de String

36. A NOTAÇÃO HÚNGARA
Com o as novas linguagens, técnicas nelas
utilizadas e testes automatizados, a notação
húngara se mostra desnecessária. Não
precisamos preocupar com o redução dos nome
das variáveis é melhor usar nomes siginificativos.
• PhoneNumber phoneNumber;

37. CLASSES
Devem ser pequenas
Ter uma única responsabilidade (SRP)
Classe tem que ser organizada em variáveis e
métodos
Sempre priorizar o encapsulamento.
Nomes de classes normalmente devem ser
representadas como substantivos.

38. CLASSES
Class Pedido {
void emitirPedido();
void gerarNotaFiscal();
}
class Pedido {
void emitirPedido();
}
Class NotaFiscal {
void gerarNotaFiscal();
}

39. SINGLE RESPONSIBILITY
PRINCIPLE (SRP)
O princípio da responsabilidade única afirma que
cada classe deve ter uma única responsabilidade,
e essa responsabilidade deve ser totalmente
encapsulado pela classe.
Todos os seus serviços devem ser estreitamente
alinhados com essa responsabilidade.
http://en.wikipedia.org/wiki/Single_responsibility_principle

40. FUNÇÕES (MÉTODOS)
Devem ser pequenas.
Ter uma única responsabilidade (SRP).
Classe tem que ser organizada em variáveis e
métodos.
Sempre priorizar o encapsulamento.
Funções devem ser verbos.
Evite repetição (DRY – Don’t Repeat Yourself)

41. FUNÇÕES (MÉTODOS)
Prefira poucos parâmetros
Trate erros antes de apresentar ao usuário
(try/catch)
Se atente a identação.
Nomes de métodos normalmente devem ser
representadas como verbos.

42. MÉTODOS NÃO DEVE TER MUITOS
PARÂMETROS:
Se tiver que fazer:
• public save (String name, String email, Integer age)
Faça:
• public save (Person person)

43. COMENTÁRIOS
Se o código estiver bem explicado, comentário não
é necessário.
Para controlar versão de código não use
comentários, prefira controles de versões (SVN,
GIT)
Se tiver que explicar seu código, refratore-o (Deixe
ele limpo)
Comentários podem não ser atualizado, podendo
“mentir” sobre a responsabilidade do código
Não misture várias linguagem (Ex: html, texto, etc)

44. FORMATAÇÃO
Classes menores são melhor entendíveis
Mantenha a indentação
Limite suas linhas (120 caracteres – uncle bob)
Combine com a equipe qual será a formatação
Mantenha contextos relacionados próximos

45. TRATAMENTO DE
ERROS
Crie primeiro sua estrutura try-catch-finally
Sempre lance exceções ao invés de retornar um
erro para o usuário.
Forneça exceções com contexto.
Não retorne null
Não passe null

46. Crie testes
Para teste use TDD (Test-driven development)

47. Resumindo,
Um código limpo é:
 Deve ser eficiente.
 Deve ter uma lógica direta que dificulte o encobrimento de bugs.
 Deve ter dependências mínimas.
 Deve facilitar a manutenção e o tratamento de erro.
 Deve ser legível.
 Não deve confundir o desenvolvedor.
 Deve ter testes unitários e de aceitação.
 Deve ter nomes significativos.
 Deve possibilitar apenas uma maneira, e não várias, de se fazer uma tarefa.
 Deve fazer o que o programador esperava que fizesse.

48. Código limpo, basicamente é ter um refinamento
sucessivo.
Sempre pensando em que o código pode ser
melhor, mais legível e funcional.
Siga sempre a ideia de que somos autores de
sistemas.

49. “ Ao escrever um código fonte temos que pensarmos
como autores e que o leitor terá a mesma sensação
ao ver um código limpo, que você fará, de estar
lendo um bom livro.”