Uma breve introdução ao clean code. Aprenda a identificar um código ruim e veja algumas dicas para otimizar a leitura de suas variáveis e funções.

1. Clean Code
Tiago Bencardino (tiagobencardino@gmail.com)

2.  O que é “clean code” e por que é importante?
 Escolhendo nomes com significado
 Funções
 Comentários
Agenda

3.  Facilmente entendido pelos outros
 Sem surpresas, direto
 Mínimo, sem dependências
 Feito para o mundo real, bom tratamento de erros
 Coeso
 Feito com cuidado
O que é um código limpo?

4. Sintomas de código ruim
 Medo de efetuar mudanças
 Confusão por não estar claro
 Frustração pelo tempo perdido
 Raiva por quem fez algo tao depreciável

5. Problemas
 Dificuldade em corrigir
problemas
 Perda de
desempenho/produtivid
ade do time
 Em casos críticos,
abandono do projeto

6.  “Honestidade nas pequenas coisas
não é algo pequeno” – Ditado
dinamarquês
 “Deus está nos detalhes” –
Arquiteto van der Rohe
Pequenas coisas importam

7.  Nomes são importantissimos em software
 Variáveis, funções, argumentos, classes, pacotes,
etc
 Boa parte do tempo estamos escolhendo nomes
durante a programação – devemos escolher BEM
 Todo nome deve transparecer:
 Seu objetivo (por que existe?)
 Qua sua tarefa (O que faz)
 Como é usado
Escolhendo nomes

8.  Nomes devem sempre revelar a intenção
 Se um nome requer um comentário explicando, então
provavelmente não é um bom nome
Nomes reveladores
 Que nomes representariam melhor?

9. Exemplo – Flagged cells

10. Exemplo – Flagged cells

11. Exemplo – Flagged cells

12.  Evite usar palavras-chave de outras linguages (ex:
shell do unix)
 Evite usar classes no nome das variaveis, se nao forem
de tal classe (ex: list)
 Evite usar nomes muito parecidos
Evite desinformação

13.  Evite números em série
Faça distinções reais
 Qual a diferença entre essas funções?

14.  Se você nao consegue ler uma variável sem soletrar,
provavelmente não é um bom nome (xpto, abc, etc..)
Nomes pronunciáveis

15.  pegarOBeco(); ou sair(); ?
 exterminate(); ou kill(); ?
 Em geral, nomes como esses só tem signicado
durante um curto periodo de tempo
Evite piadas e gírias

16.  Classes devem SEMPRE ser substantivo: Car, Person,
LoginView, etc.
 Métodos devem SEMPRE ser verbos
 Uma boa prática é prefixar em ‘get’, ‘set’ e ‘is’ para
metodos de acesso. Essa padrão pode variar
dependendo da linguagem.
 Ao sobrescrever construtores, metódos factory
estáticos com descricao dos argumentos é
interessante.
Classes e métodos/funções

17.  Tamanho:
 Regra 1: funções devem ser pequenas
 Regra2: devem ser menores ainda
 Blocos if, else, while: devem conter apenas 1 linha,
com a chamada para outro metodo. Evite
aninhamento de blocos
Funções

18.  Faça apenas uma coisa – tente extrair um pedaço do
método e pensar em outro nome
 Tenha apenas um nível de abstração
 Ideia prática: prefixo TO
Funções Atômicas

19.  Uma função deve, apenas:
 Fazer algo
 Responder algo
Separação de objetivo

20.  Evite duplicação de código
 Um código reescrito três vezes representa três
pontos de mudança no futuro
 E três oportunidades de falha
 Lembre-se: programação estruturada,
orientada a aspectos, componentes e objetos
são estratégias para eliminar duplicação
DRY – Don’t repeat yourself

21.  Prefira lançar exceções a retornar “error code” – se a
linguagem der suporte
Erros

22.  Existem muitas técnicas para escrever um bom
código
 Aplicar essas técnicas exigem tempo, treino e
paciência, mas o ganho de produtividade no futuro
compensa
 Não tenha medo de refatorar
Conclusão