Cleaner-Code-CentralIT-2015

1 de 80www.centralit.com.br | valdemar.junior@centralit.com.br
Cleaner Code
Por um mundo com menos xingamentos

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.

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

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.

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.

Médico e Paciente

Evolução contínua

Clean Code
”Qualquer um consegue escrever código que
um computador entende. Bons programadores
escrevem código que humanos entendem.”
Martin Fowler

Como conquistar isso?

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.”

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.”

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.

Nomes Significantes

Utilize nomes buscáveis para
números e Strings
Ex.: X = 20
para X = VALOR_HORA;

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.

Evite condições negativas. Elas são um pouco
mais difíceis de entender. Quando possível,
deveria ser expressado como positiva.

Utilize Enums ao invés de Constantes

Nome de Classes e Métodos
Classes Pronomes. Ex.: Paciente, WikiPage,
Conta.
•Métodos Verbos: deletar, postar, curtir,
desenhar.

Sobrecarga de Construtores
Utilize métodos estáticos que descrevam os
argumentos.

Escolha uma palavra por Conceito
Ex.: Buscar..., recuperar..., get..., pegar...
Não use mesmo termo para coisas distintas.

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.

Blocos e Identação
If, else e while deveriam ter apenas
uma linha de código, provavelmente
uma função.

Mantém pequeno e adiciona valor de
documentação, por que a função pode
ter um bom e descritivo nome.

Métodos curtos tendem a fazer uma
coisa por vez, adicionando coesão.

Switches
Grandes, quebram o SRP e se um novo
tipo for adicionado irá crescer mais.

Switches
Solução: Definir o switch em uma
classe abstrata e “não deixar
ninguém ver”.
Utilizar polimorfismo.

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.”

Argumentos de métodos
Ideal: ZERO.
Quantidade de parâmetros superior a 3
devem ser evitados e quando utilizados
devem ser justificados.

Argumentos de métodos
São difíceis de entender e de testar.

Métodos com UM argumento
Você faz uma pergunta sobre o
argumento.

Opera em cima desse argumento,
transformando-o em outra coisa.
InputStream fileOpen(“nome_arquivo”);

Argumentos FLAG
São feios. Não é uma boa prática, além de
declarar que o método tem mais de uma
responsabilidade.

Argumentos FLAG

Métodos com DOIS argumentos
Mais difícil de entender, mas as vezes é
OK.
Ex.: new Point(0,0);

Métodos com DOIS argumentos
As vezes pode levar ao erro.
Ex.: assertEquals(expected, actual);

Métodos com TRÊS argumentos
Utilizar objetos/classes como
argumento.

Utilizar objetos/classes como
argumento.
Ex.: Pega exemplo do nome social

Métodos
Qualquer método que faça você
verificar a declaração ou sua
implementação, seria um tempo
desperdiçado.

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.

Exceptions
Prefira Exceptions à códigos de erro.

Exceptions – Códigos de erro
São feios, confundem a estrutura de
código com o processo/tratamento de
erro.

Exceptions – Exceções
Fornece uma ótima separação do que
o código faz, deixando fácil de
entender e de modificar.

Exceptions – Boas práticas
Utilize try-catch primeiro.
Catch tem que deixar o sistema
consistente.

Exceptions – Boas práticas

Exceptions – Não retorne NULL
lPrefira lançar uma Exception ou retornar
um objeto especial ao invés de NULL.

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.

Exceptions
Utilize unchecked exception.

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.

Comentários
Comentários são compensações para
nossas falhas em nos expressar no código.

Comentários
Se você acha que precisa escrever um
comentário, tente pensar novamente e
expresse o que você quer no código.

Por que comentários são ruins?
Por que eles mentem. Não sempre e não
intencionalmente, mas com muita
frequência.

Noise Comments
Get's / Set's
Construtores padrão
Gerados pela IDE

Comentário Informativo
Retorno de métodos abstratos.
TODO's.
Ampliar a importância em algo, API
Públicas.

Positions Markers
lEx.: // Actions //////////////////

Positions Markers

Comentários
Pessoas não deletam isso. Eles pensam
que existe uma razão que é muito
importante para não deletá-los

Comentários

Classes
lDeveriam ser pequenas. O quanto
pequenas? Não pequenas em quantidade
de linhas, mas em responsabilidades.

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...

Classes
lUma classe deve ser aberta para
extensão e fechado para modificação.

Design Simples
lExecute todos os testes.
lRemova duplicações.
lExpresse a intenção do programador.
lMinimize o número de classes e métodos.

REGRA DOS ESCOTEIROS
Deixe a área do acampamento
mais limpa do que como você
a encontrou.

Finalmentes
•Os nomes devem ser pronunciáveis.
•Evite encodings.

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.

Mensagem
Redefina o código, divida funções, mude
nomes, elimine duplicações, deixe os
métodos curtos e reordene-os.

Obrigado!
E-Mail
Valdemar.junior@centralit.com.br

Cleaner-Code-CentralIT-2015

Mais conteúdo relacionado

Destaque (9)

Semelhante a Cleaner-Code-CentralIT-2015 (20)

Cleaner-Code-CentralIT-2015