O documento discute princípios e práticas para escrever código limpo e de alta qualidade, incluindo: (1) dividir funções em unidades menores com uma única responsabilidade; (2) usar nomes significativos para variáveis, funções e classes; (3) minimizar duplicação de código através do princípio DRY.
1. 1 de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Cleaner Code
Por um mundo com menos xingamentos
2. 2 de 80www.centralit.com.br | valdemar.junior@centralit.com.br
O LIVRO
Robert C. Martin (Uncle Bob)
Programador desde 1970;
Fundador e Presidente Object
Mentor Inc.
lDesigning Object-Oriented C++
Applications using the Booch
Method. 1995.
lAgile Software Development:
Principles, Patterns and Practices.
2002.
6. 6 de 80www.centralit.com.br | valdemar.junior@centralit.com.br
SonarQube
“É uma ferramenta opensource para análise e
gerenciamento de qualidade de código que
oferece um relatório visual e a evolução
histórica do código.”
www.sonarqube.org
9. 9 de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Situação
Quem nunca pegou um código que deveria
levar horas e levou semanas para ser corrigido?
Manter o código mais limpo possível.
10. 10de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Isso é preocupante pra nós?
Toda vez que você escreve um Bad Code, você
está fazendo parte do problema.
13. 13de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Clean Code
”Qualquer um consegue escrever código que
um computador entende. Bons programadores
escrevem código que humanos entendem.”
Martin Fowler
16. 16de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Single Responsibility Principle(SRP)
”Uma classe deve ter um, e apenas um, motivo
para ser modificada. Esse princípio também é
chamado de coesão e implica em dizer que uma
classe deve fazer uma única coisa e fazê-la
bem.”
17. 17de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Princípio Don't Repeat Yourself (DRY)
”A duplicação (seja ela acidental ou proposital)
pode levar a pesadelos de manutenção, além
de atrapalhar a refatoração e gerar
contradições lógicas.”
18. 18de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Nomes Significantes
•Leva tempo, mas ajuda muito mais.
•Teremos programadores mais felizes.
•Deve-se dizer o que faz, por que existe e como
usá-la.
•Se precisar de comentários, não é um nome
significante.
23. 23de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Encapsule condições
Lógica booleana já é difícil o bastante entender.
Se não vier dentro de um contexto de um if ou
while.
26. 26de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Encapsule condições
Evite condições negativas. Elas são um pouco
mais difíceis de entender. Quando possível,
deveria ser expressado como positiva.
28. 28de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Nome de Classes e Métodos
Classes Pronomes. Ex.: Paciente, WikiPage,
Conta.
•Métodos Verbos: deletar, postar, curtir,
desenhar.
29. 29de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Sobrecarga de Construtores
Utilize métodos estáticos que descrevam os
argumentos.
30. 30de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Escolha uma palavra por Conceito
Ex.: Buscar..., recuperar..., get..., pegar...
Não use mesmo termo para coisas distintas.
31. 31de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos
•Regra 1: Deveriam ser pequenas.
•Regra 2: Deveriam ser menores do que isso.
•O quanto pequeno deveria ser? (linhas)
De duas a cinco linhas.
32. 32de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Blocos e Identação
If, else e while deveriam ter apenas
uma linha de código, provavelmente
uma função.
33. 33de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Blocos e Identação
Mantém pequeno e adiciona valor de
documentação, por que a função pode
ter um bom e descritivo nome.
34. 34de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Blocos e Identação
Métodos curtos tendem a fazer uma
coisa por vez, adicionando coesão.
35. 35de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Switches
Grandes, quebram o SRP e se um novo
tipo for adicionado irá crescer mais.
36. 36de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Switches
Solução: Definir o switch em uma
classe abstrata e “não deixar
ninguém ver”.
Utilizar polimorfismo.
37. 37de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Princípio de Ward
“Você sabe quando está trabalhando em
um clean code quando cada
rotina/método/classe faz o que realmente
você espera.”
38. 38de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Argumentos de métodos
Ideal: ZERO.
Quantidade de parâmetros superior a 3
devem ser evitados e quando utilizados
devem ser justificados.
39. 39de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Argumentos de métodos
São difíceis de entender e de testar.
40. 40de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos com UM argumento
Você faz uma pergunta sobre o
argumento.
42. 42de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos com UM argumento
Opera em cima desse argumento,
transformando-o em outra coisa.
InputStream fileOpen(“nome_arquivo”);
44. 44de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Argumentos FLAG
São feios. Não é uma boa prática, além de
declarar que o método tem mais de uma
responsabilidade.
46. 46de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos com DOIS argumentos
Mais difícil de entender, mas as vezes é
OK.
Ex.: new Point(0,0);
47. 47de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos com DOIS argumentos
As vezes pode levar ao erro.
Ex.: assertEquals(expected, actual);
48. 48de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos com TRÊS argumentos
Utilizar objetos/classes como
argumento.
50. 50de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos com TRÊS argumentos
Utilizar objetos/classes como
argumento.
Ex.: Pega exemplo do nome social
51. 51de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos
Qualquer método que faça você
verificar a declaração ou sua
implementação, seria um tempo
desperdiçado.
52. 52de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Métodos
Funções deveriam fazer ou perguntar
algo. Mudar o estado do objeto ou
retornar alguma informação sobre ele
e não os dois.
54. 54de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Exceptions – Códigos de erro
São feios, confundem a estrutura de
código com o processo/tratamento de
erro.
55. 55de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Exceptions – Exceções
Fornece uma ótima separação do que
o código faz, deixando fácil de
entender e de modificar.
56. 56de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Exceptions – Boas práticas
Utilize try-catch primeiro.
Catch tem que deixar o sistema
consistente.
58. 58de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Exceptions – Não retorne NULL
lPrefira lançar uma Exception ou retornar
um objeto especial ao invés de NULL.
59. 59de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Exceptions – Não retorne NULL
lNão tem boas práticas para tratar NULL.
A forma racional de tratar isso é não
passar/retornar null.
61. 61de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Comentários
Não comente código ruim, reescrevá-os.
Comentários não ajudam um código sujo! Em
geral, servem para explicar um código ruim.
62. 62de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Comentários
Comentários são compensações para
nossas falhas em nos expressar no código.
63. 63de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Comentários
Se você acha que precisa escrever um
comentário, tente pensar novamente e
expresse o que você quer no código.
64. 64de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Por que comentários são ruins?
Por que eles mentem. Não sempre e não
intencionalmente, mas com muita
frequência.
65. 65de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Noise Comments
Get's / Set's
Construtores padrão
Gerados pela IDE
66. 66de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Comentário Informativo
Retorno de métodos abstratos.
TODO's.
Ampliar a importância em algo, API
Públicas.
69. 69de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Comentários
Pessoas não deletam isso. Eles pensam
que existe uma razão que é muito
importante para não deletá-los
72. 72de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Classes
lDeveriam ser pequenas. O quanto
pequenas? Não pequenas em quantidade
de linhas, mas em responsabilidades.
73. 73de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Classes
lO nome da classe deve descrever quais
responsabilidades está preenchida. Nós
deveríamos descrever uma classe com +-
25 palavras, sem usar Se, e, ou, mas...
74. 74de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Classes
lUma classe deve ser aberta para
extensão e fechado para modificação.
75. 75de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Design Simples
lExecute todos os testes.
lRemova duplicações.
lExpresse a intenção do programador.
lMinimize o número de classes e métodos.
76. 76de 80www.centralit.com.br | valdemar.junior@centralit.com.br
REGRA DOS ESCOTEIROS
Deixe a área do acampamento
mais limpa do que como você
a encontrou.
77. 77de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Finalmentes
•Os nomes devem ser pronunciáveis.
•Evite encodings.
78. 78de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Finalmentes
Não tenha medo de mudar código. Seremos
gratos quando você mudar (para melhor!).
Seguir essas regras e melhorar a leitura do seu
código é um valor que será pago a curto e a
longo prazo.
79. 79de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Mensagem
Redefina o código, divida funções, mude
nomes, elimine duplicações, deixe os
métodos curtos e reordene-os.