Clean Code
Tiago Bencardino (tiagobencardino@gmail.com)
 O que é “clean code” e por que é importante?
 Escolhendo nomes com significado
 Funções
 Comentários
Agenda
 Facilmente entendido pelos outros
 Sem surpresas, direto
 Mínimo, sem dependências
 Feito para o mundo real, bom trat...
Sintomas de código ruim
 Medo de efetuar mudanças
 Confusão por não estar claro
 Frustração pelo tempo perdido
 Raiva ...
Problemas
 Dificuldade em corrigir
problemas
 Perda de
desempenho/produtivid
ade do time
 Em casos críticos,
abandono d...
 “Honestidade nas pequenas coisas
não é algo pequeno” – Ditado
dinamarquês
 “Deus está nos detalhes” –
Arquiteto van der...
 Nomes são importantissimos em software
 Variáveis, funções, argumentos, classes, pacotes,
etc
 Boa parte do tempo esta...
 Nomes devem sempre revelar a intenção
 Se um nome requer um comentário explicando, então
provavelmente não é um bom nom...
Exemplo – Flagged cells
Exemplo – Flagged cells
Exemplo – Flagged cells
 Evite usar palavras-chave de outras linguages (ex:
shell do unix)
 Evite usar classes no nome das variaveis, se nao for...
 Evite números em série
Faça distinções reais
 Qual a diferença entre essas funções?
 Se você nao consegue ler uma variável sem soletrar,
provavelmente não é um bom nome (xpto, abc, etc..)
Nomes pronunciáve...
 pegarOBeco(); ou sair(); ?
 exterminate(); ou kill(); ?
 Em geral, nomes como esses só tem signicado
durante um curto ...
 Classes devem SEMPRE ser substantivo: Car, Person,
LoginView, etc.
 Métodos devem SEMPRE ser verbos
 Uma boa prática é...
 Tamanho:
 Regra 1: funções devem ser pequenas
 Regra2: devem ser menores ainda
 Blocos if, else, while: devem conter ...
 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
 ...
 Uma função deve, apenas:
 Fazer algo
 Responder algo
Separação de objetivo
 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 oportun...
 Prefira lançar exceções a retornar “error code” – se a
linguagem der suporte
Erros
 Existem muitas técnicas para escrever um bom
código
 Aplicar essas técnicas exigem tempo, treino e
paciência, mas o gan...
Clean code - Mantenha seu código limpo
Próximos SlideShares
Carregando em…5
×

Clean code - Mantenha seu código limpo

721 visualizações

Publicada em

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.

Publicada em: Tecnologia
1 comentário
2 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
721
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
7
Comentários
1
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Claro, com boas abstracoes, sem surpresas, bons nomes
    Sem features escondidas
  • Int tempoGastoEmDias;
    Int diasDesdeCriacao;
    Int diasDesdeModificacao;
  • accountGroup, accounts…
  • Source e destination
  • New Complex (23.0); , Complex.FromRealNumber(23.0)
  • Clean code - Mantenha seu código limpo

    1. 1. Clean Code Tiago Bencardino (tiagobencardino@gmail.com)
    2. 2.  O que é “clean code” e por que é importante?  Escolhendo nomes com significado  Funções  Comentários Agenda
    3. 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. 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. 5. Problemas  Dificuldade em corrigir problemas  Perda de desempenho/produtivid ade do time  Em casos críticos, abandono do projeto
    6. 6.  “Honestidade nas pequenas coisas não é algo pequeno” – Ditado dinamarquês  “Deus está nos detalhes” – Arquiteto van der Rohe Pequenas coisas importam
    7. 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. 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. 9. Exemplo – Flagged cells
    10. 10. Exemplo – Flagged cells
    11. 11. Exemplo – Flagged cells
    12. 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. 13.  Evite números em série Faça distinções reais  Qual a diferença entre essas funções?
    14. 14.  Se você nao consegue ler uma variável sem soletrar, provavelmente não é um bom nome (xpto, abc, etc..) Nomes pronunciáveis
    15. 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. 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. 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. 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. 19.  Uma função deve, apenas:  Fazer algo  Responder algo Separação de objetivo
    20. 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. 21.  Prefira lançar exceções a retornar “error code” – se a linguagem der suporte Erros
    22. 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

    ×