Apresentação sobre temas abordado no livro Clean Code de Robert C. Martim. Os benefícios sobre manter seu código limpo. Quais prejuízos um código sujo pode trazer para sua empresa. Como se expressar no seu código dispensando o uso de inúmeros comentários que poluem o código.

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