O documento aborda a importância de escrever código limpo, enfatizando a manutenção, legibilidade e eficiência. Discute os custos de um código confuso e recomenda práticas como nomes significativos, funções concisas e a importância de testes. Também destaca que um bom design de código deve seguir princípios como a responsabilidade única e evitar duplicações.

1. Clean Code
Robert C. Matin
"Honestidade em pequenas coisas não é uma coisa pequena“

2. O que você sente ?
O que você sente quando encontra um código ruim ?
Você já sentiu raiva de quem fez o código no qual você está
trabalhando ?
Já sentiu vontade de apagar tudo o que alguém fez e fazer tudo
de novo ?
“Amarás o teu próximo como a ti mesmo”

3. O que é código limpo ?
• Fácil manutenção
• Elegante
• Eficiente
• Legível
• Sem duplicações
• Simples
• Cuidadoso
• Feito para o problema
• Direto
• Produtividade
Entre muitas outras respostas...

4. 5S na codificação
• Seiri (Organização) – Saber onde estão as coisas, nomes
adequados.
• Seiton(Arrumação) – Um pedaço de código deve estar aonde
você espera encontrar.
• Seiso(Limpeza) – Local de trabalho cheio de
fios, sujeira, comida. Código cheio de comentários
desnecessários.
• Seiketsu(Padronização) – A equipe está de acordo em manter
o local de trabalho limpo?
• Shutsuke(Autodisciplina)- Disciplina ao seguir as
práticas, refletir frequentemente isso no trabalho e estar
disposto a mudar.

5. O custo de um código confuso
• Lentidão.
• Uma alteração, várias falhas.
• Remendos.
• Produtividade diminui.
• Alocação de mais recursos.

6. Código ruim acabou com a
empresa
• Empresa tinha um produto extraordinário e popular.
• Lançamentos frequentes.
• Não corrigiam todos BUGS nas novas versões.
• Lentidão.
• Travamento.
Resultado: Saiu do mercado
Motivo: Código ruim.
Apressaram o lançamento das entregas, com isso o código ficou uma
zona, cada vez era adicionados mais recursos e o código
piorava, chegou um momento que não era possível mais gerencia-lo.

7. A culpa é de quem ?
• Mas e ai, não temos tempo pra ficar refatorando e limpando
código, a culpa é da gerencia e do marketing que determina prazos
curtos.
• Quem estima esforço de desenvolvimento ?
• Um produto entregue rápido agrega mais valor do que um produto
de qualidade?
• Quer economizar tempo no desenvolvimento ? Esse tempo será
utilizado em dobro na manutenção.

8. Para pensar...
• Uma única janela pode causar a
degradação de uma casa.
• Tempo gasto na leitura pela escrita é
de 10 por 1.
• Escoteiros: Deixe a área do
acampamento mais limpa do que
como você a encontrou.

9. Como identificar um código
sujo ?

10. Nomes significativos
Nomes estão em todo o código, usamos nomes em tudo. Então
temos que fazer isso bem feito.
Porque ele existe.
Como é usado.
O que ele faz.
Revelem seus propósitos.

11. Nomes significativos
int d; //tempo decorrido em dias;
Se um nome requer um comentários, ESTÁ ERRADO. O nome deve revelar
seu propósito.
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

12. Nomes significativos
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[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}

13. Nomes significativos
CUIDADO !
Evite informações erradas, interpretações podem ser diferentes.
Ex: accountList – List significa um tipo de variável para programadores, e o
tipo da variável não deve estar no nome.
accountList – accounts , accountGroup
intAmount – amount
Evite nomes muito parecidos:
XZYControllerForEfficientHandlingOfStrings
XYZControllerForEfficientStorageOfStrings

14. Nomes significativos
Evite o uso de “L” minúsculo e “O” maiúsculo , podem ser
confundidos com 1 e 0.
Faça distinções significativas, não use sequenciais.
public static void copyChars(char a1[], char[] a2)
{
for(int i=0 ; i< a1.length;i++){
a2[i] = a1[i] ;
}
}

15. Nomes significativos
• Use nomes pronunciáveis, evite usar palavras que não são
palavras.
class Customer {
DtaRcrd102{
private Date private Date genymdhms;
generationTimestamp;
private Date private Date modymdhms;
modificationTimestamp;
private final String recordId = "102"; = "102";
private final String pszqint
} }
Ai vc acessa minha classe
customer, eepega oovalor da
dtarcd102, pega valor da
variavel modymdhms!!
variável
modificationTimestamp !!

16. Nomes significativos
• Nomes passiveis de busca, evite uma letra só.
• Não use prefixos de variáveis membro. Ex: m_name.
• Classes – substantivos.
• Métodos – verbos.
• Não use humor, gírias , etc.
• Use uma palavra por conceito. (Controller,Manager).
• Não use trocadilhos. Palavras que realizem mais de uma ação.
Ex: Add(adicionar), Add(concatenar).
• Contexto significativo, só utilizar prefixo quando o namespace
e classe não resolver.

17. Funções
• Devem fazer apenas UMA coisa.
• Nomes descritivos - Deve descrever exatamente o que a
função faz, não se preocupar em utilizar nomes longos, nomes
longos são melhores que comentários longos.
• Ler o código de cima para baixo, devem ser ordenadas de
forma decrescente.

18. Funções
Parâmetros
• Quantidade ideal: 0.
• Mais de 3 parâmetros somente em casos muitos
especiais, dificulta os testes.
• Não utiliza booleano, implica que a função faz mais de uma
coisa.
• Evite parâmetros de saída.
• Funções devem fazer ou responder a algo.

19. Funções
Evite efeitos colaterais
Evitar que sua função implique em alterações em fazer outras coisas
além do que diz fazer:
public boolean checkPassword(String userName, String password){
User user = UserGateway.findByName(userName);
if(user != User.NULL){
String codedPhrase = user.getPhraseEncodedByPassword();
String phrase = cryptographer.decrypt(codedPhrase,password);
if("Valid Password".equals(phrase))
{
Session.initialize();
return true;
}
}
return false;
}

20. Comentários

21. Comentários
• Podem ser uteis se colocados nos lugares certos.
• Comentários mentem.
• Não recebem manutenção.
• Um dos motivos mais comuns para se escrever comentário é
código ruim.
• Pensou em comentar ? Limpe, refatore antes.

22. Comentários
Comentários RUIM
• Redundante, explicar o que já está explicito.
• Enganadores, utilizados para cobrir gambiarras.
• Ruidosos, indicam o óbvio.
• Evite comentário se é possível utilizar método ou variável.
• Marcadores de posição, usar raramente, acaba se tornando um ruído no
código.
• Ao lado de chaves de fechamento.
• Créditos e autoria.
• Explicação de código em comentários.
• Comentários em HTML.
• Informações excessivas .
• Conexões nada óbvias, comentários que devem ser explicados.
• JavaDoc em códigos que não são públicos.
• Entre outros...

23. Comentários
Comentários BOM
• Diretos
• Fontes externas
• Alerta sobre consequências
• TODO.
• Explicação de intenção
• Destaque
• JavaDoc em API’S públicas

24. Formatação
Vertical
• Não é regra mas geralmente classes tem 200 , e no máximo
500 linhas, classes menores são mais fáceis de entender.
• Conceitos que estão relacionados devem ficar verticalmente
próximos um dos outros.
Horizontal
• Alguns desenvolvedores sugerem o limite de 120 caracteres
por linha.
• Identação, ajuda a visualizar o escopo e identificar regras e
situações mais rápido.

25. Tratamento de Exceção
• Não retorne código de erros.
• Lançamento de exceções:
 Evita o tratamento de retorno.
 Muitos lançamentos podem dificultar a manutenção.
• Não retornar null.
• Não permitir que null seja passado como parâmetro.
• Crie mensagens informativas nas exceções.
• Não trate regra de negócios no tratamento de erros.

26. Testes
• Garantir que cada pedaço do código está fazendo o esperado.
• Leis dos TDD:
• Você não pode escrever o código até que você tenha criado um
teste falhando.
• Você não pode criar mais testes do que seja necessário para
falhar.
• Você não pode escrever mais código do que o suficiente pra
passar o teste que esta falhando.

27. Testes
Mantenha seus testes limpos!
Os testes precisam sofrer alterações da mesma forma que os
códigos.
Quanto mais sujo o teste mais difícil será dar manutenção.
Um conceito por teste.
Separe um teste que esteja testando mais de um conceito em
vários teste.
Facilite o entendimento de cada teste.

28. Limites
Código de terceiros.
Evite passar objetos de API’s adiante, mantenha-o na classe ou
família de classes.
Testes de aprendizagem
• Realizar testes sobre as API’s de terceiros.
• Junto com a documentação da API realizar testes sob as
funcionalidades nas quais desejam usar.
• Ajudam a aumentar o rendimento, quando há atualização da
API basta executar os testes de novo.

29. Classes
Segundo padrões java devem começar com as variáveis.
-públicas estáticas e constantes.
-privadas estáticas e variáveis.
-privadas instancias e variáveis.
Funções vem depois das variáveis.

30. Classes
Seguem as mesmas regras dos métodos:
1. Devem ser pequenas.
2. Devem ser menores ainda.
Principio da Responsabilidade única(SRP)
Uma classe deve ter apenas 1 responsabilidade.
Para analisarmos se o tamanho da classe está ideal devemos
medir a responsabilidade dela.

31. Emergente
Regras básicas para criar um design de código e
estrutura, aplicando os conceitos de SRP E DIP.
Simple Design de Kent Beck
• Rode todos os testes.
• Remova duplicação.
• Expresse sua intenção.
• Diminua o número de classes e métodos.

32. Emergente
Rode todos os testes
Sistemas que não podem ser testados não podem ser
verificados. Logo, pode-se dizer que um sistema que não pode
ser verificado jamais deveria ser implementado.
Quanto mais testes, mais boas maneiras e princípios seguiremos
para evitar o acoplamento de nosso código.

33. Emergente
Sem duplicação
Códigos iguais ou implementações que fazem a mesma coisa.
Principal inimigo para um sistema bem desenvolvido.
Representa trabalho, risco e complexidade desnecessária extra.

34. Emergente
Expresse sua intenção
Muitos de nós já produzimos e trabalhamos com códigos
confusos, isso porque ao desenvolver pensamos somente no nosso
entendimento, nosso conhecimento no problema naquele momento é
profundo, mas e quem vai manter o código conseguirá entender ?
• Escolha bons nomes.
• Métodos e classes pequenas.
• Separe responsabilidades.
• Nomenclatura padrão.
Reduz os defeitos e custos da manutenção.
O próximo pode ser você!

35. Emergente
Menos classes e métodos
Tentar manter nosso sistema pequeno ao mesmo tempo que
mantemos nossos métodos e classes pequenas.
Dogmatismo exagerado.
Abordagem pragmática.
Essa é a ultima das prioridades, a menos importante.

36. Maus Cheiros
• Comentários obsoletos e redundantes.
• Comentários pobres.
• Código comentado.
• Testes que requerem mais de um passo.
• Muitos parâmetros ou parâmetros boolean.
• Métodos mortos ou que fazem muita coisa.
• Duplicação.
• Inconsistências.
• Intenção obscura.

37. Maus Cheiros
• Responsabilidades fora de contexto.
• Variáveis e funções inexpressivas.
• Despadronização.
• Números mágicos.
• Métodos fazendo mais de uma coisa.
• Desencapsulamento.
• Nomes pequenos e inexpressivos.
• Efeitos colaterais.
• Testes insuficientes.

38. Assuma esse compromisso