Boas Práticas

Clean Code
Técnica para um código limpo

Rodrigo Kono
MVP, MCTS, MCPD, MCT, MCP
@rodrigokono
www.rodrigokono.net
Há duas razões pelas quais
você está nesta palestra:
1. Você é um programador
2. Deseja se tornar um ainda melhor.
 ÓTIMO! PRECISAMOS DE
PROGRAMADORES MELHORES
Robert C. Martin
The Clean Coder

Robert C. Martin (Uncle Bob); Programador desde 1970;

Fundador e Presidente Object Mentor Inc.
Livros:
Designing Object-Oriented C++ Applications using the Booch Method. 1995.
Agile Software Development: Principles, Patterns and Practices. 2002.
Clean Code: A Handbook of Agile Software Craftsmanship.
O que é Clean Code?
• Eficiente
• Simples
• Direto ao ponto
• Mínimas dependências
• Sem duplicação
• Fácil manutenção
• Padrões definidos
• Fácil leitura e
entendimento
• Coberto de testes
• Elegante
Síndrome da janela quebrada
Que porta representa o seu código?
 "Qualquer um consegue escrever
código que um computador entende.
Bons programadores escrevem
código que humanos endentem“

Martin Fowler
Funcionar é o mínimo que se espera
Ah! Mas o cronograma é
apertado.

Não tenho tempo para

frescura!

Meu chefe está me

pressionando!

Quero mostrar produtividade.

Filho feio não tem pai!
Afinal, de quem é a culpa?
É nossa!
 Como mensurar a
qualidade de um código?
OK! Vamos ao que interessa
NOMES SIGNIFICATIVOS
Nomes significativos

int d; // tempo transcorrido em dias

int tempoTranscorridoEmDias;
int diasDesdeCriacaoDoArquivo;
int diasDesdeModificacaoDoArquivo;
int idadeDoArquivoEmDias;
Use nomes que revelem a intenção
Nomes significativos

public List<int> obter() public List<int> obtemDiasMarcados()

{ {
int[] x = new int[3]; int[] diaMarcado = new int[3];
List<int> lista1 = new List<int>(); List<int> diasMarcados = new List<int>();
for (int i = 0; i < lista; i++) for (int dia = 0; dia < mes; dia++)
{ {
if (x[0] == 4) if (diaMarcado[STATUS] == MARCADO)
{ {
lista1.Add(x[0]); diasMarcados.Add(diaMarcado[STATUS]);
} }
} }
return lista1; return diasMarcados;
} }
Nomes significativos

public List<int> obtemDiasMarcados()

{
int[] diaMarcado = new int[3];
List<Dia> diasMarcados = new List<Dia>();

foreach (Dia dia in mes)

{
if (dia.marcado)
{
diasMarcados.Add(dia);
}
}
return diasMarcados;
}
Use nomes pronunciáveis
Nomes significativos

class DtaRcrd102
{
private DateTime gerdmahms;
private DateTime moddmahms;
private string pszqint = "102";
}

class Cliente
{
private DateTime gerarDataHora;
private DateTime modificarDataHora;
private string idRegistro = "102";
}
Use nomes buscáveis
Nomes significativos
for (int j = 0; j < 30; j++)
{
s = (t[j]*4)/5;
}

const int DIAS_DE_TRABALHO_POR_SEMANA = 5;

int soma = 0;
int diasReaisDeTrabalho = 4;

for (int j = 0; j < NUMERO_DE_TAREFAS; j++)

{
int tarefasPorDia = trabalhoEstimado[j] * diasReaisDetrabalho;
int taredasPorSemana = (dias / DIAS_DE_TRABALHO_POR_SEMANA);

soma += taredasPorSemana;
}
Nomeando classes e métodos
Nomes significativos
Classes
representadas por substantivos
ex: Cliente, Perfil, Estoque, etc

Métodos
representadas por verbos ou frases verbais
ex: enviarPagamento, salvar, etc.
FUNÇÕES
Seja pequeno
Funções
• Menos é mais!
• Extraia trechos em métodos privados.
• Lembre-se dos nomes significativos
• Vá direto ao ponto.
Funções
Faça uma coisa só!
Funções

• Repare a endentação (sim, é assim que escreve)

• Muitos níveis ~= muita responsabilidade
• O método deve fazer uma única coisa, e bem!
• Está fazendo mais de uma coisa? Extraia.
Leia o código de cima pra baixo
Funções
• Seu código deve ser lido como uma
narrativa
• Temos sujeitos, verbos e predicados
• Narrativas são frases em ordem
coerente
• Lembre-se disto ao extrair em
métodos privados;
Funções
• Muitos argumentos = code smell
• Existem algumas regras para a
quantidade de argumentos
• Argumentos booleanos, em geral, não
são bons.
Funções
DRY (Don’t Repeat Yourself)
COMENTÁRIOS
Comentários não ajudam
um código sujo!
Comentários
• Em geral, servem para explicar um código ruim.
• Um bom código é auto documentado.

• Extraia para um método que faça o que diz!

Comentários aceitáveis
Comentários
• Comentários sobre licença (direitos de
uso de uma lib, por exemplo)
• Comentários informativos
• Necessidade de explicação de negócio
Comentários ruins
Comentários
• Por falta do que escrever
• Redundantes
• Documentação em APIs não públicas
• Dizendo algo que o próprio código
deveria dizer
• Código comentado =S
Comentários
FORMATAÇÃO
O que vale é a regra do time
OBJETOS E ESTRUTURA
DE DADOS
Abstração de dados
Objetos e estrutura de dados
Objetos e estrutura de dados
A lei de Demeter
Objetos e estrutura de dados
Um método M de uma classe C só conhece:

• Métodos de C
• Objetos criados por M
• Objetos passados como argumentos para M
• Objetos em variáveis de instâncias de C
Demeter Law

M
TRATAMENTO DE ERRO
Exceções ao invés de
código de erro.
Tratamento de erro
Tratamento de erro
 Tratamento de exceção é uma das
coisas que um método ou função faz
Não use exceções genéricas
Não retorne null
Tratamento de erro
• Obriga o uso de if
• Pode disparar NullPointerException
• Considere: Lançar exceção ou retornar um objeto especial
Não passe null
REGRA DOS ESCOTEIROS

Deixe a área do acampamento

mais limpa do que como você a
Encontrou.
Não deixe acumular problemas!
Código ruim
cheira mal...

Torna o seu trabalho

lento e desgastante
com o passar do
tempo

Pode arruinar seu

projeto, carreira,
empresa...

Fique atento.
Falar é fácil!

O desafio é criar um código de

qualidade.
Portanto, falar é o primeiro passo de melhoria.
Using References;
Gustavo Barbosa
http://www.slideshare.net/gustavocsb

Hendrik Ebel
http://www.slideshare.net/hebel

Thiago Faria de Andrade

http://www.slideshare.net/thiagofa
END

contato@rodrigokono.net