O documento discute os princípios do código limpo, definindo-o como código fácil de entender e alterar. Ele explica que código limpo é fácil de ler, entender o fluxo e colaboração entre objetos, e fácil de estender e corrigir. O documento fornece regras gerais e específicas sobre nomes, funções, comentários, estrutura e testes para produzir código limpo.

1. Qualidade de
Software
Prof. Rennan Alves

2. Código Limpo

3. Que porta representa seu código?

4. Definição de Código Limpo
• A melhor definição de Código Limpo que encontrei foi:
“Código limpo é código fácil de entender e fácil de alterar.”

5. Fácil de entender significa
• Fácil de ler pelo autor ou por outros desenvolvedores;
• Fácil de entender o fluxo de execução de toda aplicação;
• Fácil de entender como os diferentes objetos colaboram uns com
os outros;
• Fácil de entender o papel e a responsabilidade de cada classe;
• Fácil de entender o que cada método faz;
• Fácil de entender qual é o propósito de cada expressão e variável;

6. Fácil de alterar significa
• Fácil de estender e refatorar o código
• Fácil de corrigir bugs no código;
• Fácil de introduzir as alterações sem “quebrar” nenhuma
funcionalidade;
• Fácil de testar com testes unitários já existentes e/ou fácil
de escrever os testes;
• Fácil de entender os testes;

7. Regras gerais
• Siga as convenções:
Se o projeto tem convenções e por exemplo utilizam
constantes em maiúsculo, siga sempre os padrões do
projeto.

8. Regras gerais
• Regra do escoteiro:
• “Deixe sempre o acampamento mais limpo do que você
encontrou!". Isto também vale para o código. Claro que
realizando todos os testes necessários para não impactar outras
partes do projeto e tendo a atenção de atender as entregas.

9. Regras gerais
• Causa raiz:
• Sempre procure a causa raiz do problema para que ele seja
resolvido. Soluções superficiais somando gastam tempo sem
agregar valor ao produto

10. Regras sobre entendimento do código
• Seja consistente:
• Se você executa algo de uma forma, execute todo o resto desta
mesma forma. Seja consistente na forma com que aplica o
código. Siga sempre o padrão definido.

11. Regras sobre entendimento do código
• Utilize variáveis concisas:
• Opte por variáveis concisas, mesmo que resultem em um nome
maior. Elas devem ser autoexplicativas, sem a necessidade de
comentários ou informações adicionais.

12. Regras para os nomes
• Escolha nomes descritivos:
• Escolher bons nomes para classes, variáveis e métodos é essencial
para um código limpo. Lembre-se que se você precisa explicar seu
código, então algo pode ser melhorado nele.

13. Regras para os nomes
• Faça distinções significantes:
• Utilize sempre nomes nos quais quem estiver lendo seu código
possa diferenciar seu significado de outros possíveis nomes.

14. Regras para os nomes
• Utilize nomes “pronunciáveis” e “buscáveis”
• Evite utilizar nomes difíceis de pronunciar ou inventar nomes
variáveis, classes e métodos. Lembre-se sempre da
(linguagem comum a todos os envolvidos) e da importância

15. Regras para os nomes
• Evite uso excessivo de strings
• Quem nunca perdeu horas procurando um BUG que era apenas um
problema de comparação de string? Evite digitar a mesma string
várias vezes, utilize constantes para isto.

16. Regras para funções ou métodos
• Pequenas e com apenas um objetivo:
• Mantenha suas funções ou métodos o menor possível. É melhor ter métodos
menores e reutilizáveis do que tudo dentro de um método só.

17. Regras para funções ou métodos
• Utilize nomes descritivos:
• A mesma regra dos nomes anteriormente vista aqui se aplica para este cenário.
Mantenha nomes concisos, sem caracteres especiais.

18. Regras para funções ou métodos
• Opte por poucos parâmetros:
• Evite exigir muitos parâmetros para construção do objeto.
• Cuidado com efeitos colaterais
• Evite que uma função altere valores de outra classe sem ser a dela. Isto é
chamado de efeito colateral.

19. Regras de comentários
• Um código bom é expressivo:
• Teoricamente, se você precisa comentar uma parte do seu código, é porque algo
está errado com ele, ele não está expressivo o suficiente.

20. Regras de comentários
• Não seja redundante:
• Mantenha suas funções ou métodos o menor possível. É melhor ter métodos
menores e reutilizáveis do que tudo dentro de um método só.
• Não feche os comentários:
• Não há necessidade de fechar os comentários – polui menos o código.

21. Regras de comentários
• Evite códigos comentados
• Não deixe sujeira em seu código, ao invés de deixar algo
comentado, remova ele. Hoje temos “versionadores” de código,
você pode "voltar no tempo" facilmente.
• Comentários sobre esclarecimento
• Uso interessante para os comentários são esclarecimentos sobre o
código e o processo a ser controlado – não sobre o comando a ser
executado.

22. Estrutura do código
• Separe os conceitos verticalmente
• Mantenha uma estrutura de pastas saudável e organizada.
pasta para cada arquivo, mas pode haver uma separação por
• Declare variáveis próximas de seu uso
• Não crie todas as variáveis juntas, no começo da class ou
próximas de onde serão utilizadas.

23. Estrutura do código
• Agrupe funcionalidades similares
• Se uma função pertence a um grupo dentro de um objeto,
mantenha-as sempre por perto.
• Declare funções de cima para baixo
• Ordenar as funções também é importante. Além da sua ordem de
grandeza, suas assinaturas também devem ter uma boa
organização.

24. Estrutura do código
• Mantenha poucas e curtas linhas
• Evite funções com linhas longas ou muitas linhas. Não existe um
número correto, mas com certeza quanto mais código em uma
função, mais difícil de mantê-la será.
• Não use alinhamento horizontal
• Não há necessidade de alinhar horizontalmente variáveis,
constantes ou mesmo propriedades.

25. Estrutura do código
• Use os espaços em branco corretamente
• Utilize espaço em branco para associar ou não itens relacionados.
Uma boa IDE já fará este trabalho por você.
• Não quebre a indentação
• Este item dispensa comentários. Um código não indentado não
pode ser enviado para o projeto.

26. Testes
• Cada teste deve tratar de apenas um tipo de função
• Mais de uma função por teste pode confundir e comprometer a
escrita do seu teste.
• Devem ser legíveis
• Trate seus testes como parte fundamental do seu código, não
secundária. Os testes têm que ser organizados e bem escritos
assim como o resto do seu software.

27. Testes
• Devem ser rápidos
• Um dos objetivos principais de um teste é cobrir uma pequena porção
do nosso código. Normalmente estendemos esta ideia para a maior
parte do código possível, ocasionando uma ampla gama de testes de
unidade. Então os testes devem ser de rápida execução para não
afetar o tempo do deploys da aplicação como um todo.
• Deve permitir repetição
• Devemos ter a possibilidade de repetir o mesmo teste, mas com
parâmetros diferentes.

28. Conclusão
“Todas as regras do Clean Code ajudam a diminuir o principal
problema que os sistemas enfrentam: a manutenção. Facilita a
vida do programador autor do código e de outros que
necessitam manter o código. Menos tempo, menos custo e
maior produtividade.”

29. Referência
BELFIORE, Patrícia; FÁVERO, Luiz Paulo. Pesquisa operacional
para cursos de engenharia. Elsevier Brasil, 2013.
HILLIER, F. S; LIEBERMAN, G. J. Introdução à pesquisa
operacional. 8ª. Edição. Porto Alegre: Bookman, 2006.
TAHA, H. A. Pesquisa operacional. 8ª. Edição. São Paulo:
Pearson Prentice Hall, 2008.