Boas Práticas
Clean Code
Técnica para um código limpo
Rodrigo Kono
MVP, MCTS, MCPD, MCT, MCP
@rodrigokono
www.rodrigokono....
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:
Des...
O que é Clean Code?
• Eficiente
• Simples
• Direto ao ponto
• Mínimas dependências
• Sem duplicação
• Fácil manutenção
• Padrões definidos
• F...
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“
...
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 produtividad...
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 ...
Use nomes que revelem a intenção
Nomes significativos
public List<int> obter()
{
int[] x = new int[3];
List<int> lista1 = new List<int>();
for (int i = 0; ...
Nomes significativos
public List<int> obtemDiasMarcados()
{
int[] diaMarcado = new int[3];
List<Dia> diasMarcados = new Li...
Use nomes pronunciáveis
Nomes significativos
class DtaRcrd102
{
private DateTime gerdmahms;
private DateTime moddmahms;
private string pszqint = "...
Use nomes buscáveis
Nomes significativos
const int DIAS_DE_TRABALHO_POR_SEMANA = 5;
int soma = 0;
int diasReaisDeTrabalho = 4;
for (int j = 0;...
Nomeando classes e métodos
Nomes significativos
Classes
representadas por substantivos
ex: Cliente, Perfil, Estoque, etc
Métodos
representadas por ve...
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 u...
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 ord...
Funções
• Muitos argumentos = code smell
• Existem algumas regras para a
quantidade de argumentos
• Argumentos booleanos, ...
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 ...
Comentários aceitáveis
Comentários
• Comentários sobre licença (direitos de
uso de uma lib, por exemplo)
• Comentários informativos
• Necessidade...
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ód...
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 pass...
Demeter Law
C
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 ob...
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, carrei...
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...
END
contato@rodrigokono.net
Boas práticas técnica para um código limpo (Clean Code)
Boas práticas técnica para um código limpo (Clean Code)
Próximos SlideShares
Carregando em…5
×

Boas práticas técnica para um código limpo (Clean Code)

15.047 visualizações

Publicada em

Código que simplesmente “funciona” não é suficiente, infelizmente. Código que tem valor real e é duradouro, tem de ser “limpo”! Esta track irá abordar um pouco sobre as técnicas de Clean Code, o que é um código limpo, quais suas características e como transformar seu código ruim em um código claro e legível. Atitudes que afetam nosso comportamento como desenvolvedor e que, sem dúvidas, transformam a maneira de como desenvolvemos software.

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

Nenhuma nota no slide
  • Se um nome requer um comentário, é um nome ruim.
  • Que tipo de coisas há na lista?
    O que significa o valor 4?
  • Que tipo de coisas há na lista?
    O que significa o valor 4?
  • Programar é social.
    Nosso cérebro tem o costume de ler e não de decifrar. Você conversa com o código.
  • Blocos de edentação é indício de que está fazendo muita coisa
  • Tem que valer os bytes que consomem!
  • Pode ser levado como um gosto pessoal.
    Mas valem os padrões determinados pelo time/equipe.
  • A Lei de Demeter aborda um problema específico do acoplamento e apresenta princípios para organizar e reduzir as dependências entre classes.
  • Obriga tratamento de nulo
    Tira legibilidade do código
  • Boas práticas técnica para um código limpo (Clean Code)

    1. 1. Boas Práticas Clean Code Técnica para um código limpo Rodrigo Kono MVP, MCTS, MCPD, MCT, MCP @rodrigokono www.rodrigokono.net
    2. 2. Há duas razões pelas quais você está nesta palestra: 1. Você é um programador 2. Deseja se tornar um ainda melhor.
    3. 3. ÓTIMO! PRECISAMOS DE PROGRAMADORES MELHORES Robert C. Martin
    4. 4. 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.
    5. 5. O que é Clean Code?
    6. 6. • 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
    7. 7. Que porta representa o seu código?
    8. 8. "Qualquer um consegue escrever código que um computador entende. Bons programadores escrevem código que humanos endentem“ Martin Fowler
    9. 9. Funcionar é o mínimo que se espera
    10. 10. Ah! Mas o cronograma é apertado. Não tenho tempo para frescura! Meu chefe está me pressionando! Quero mostrar produtividade.
    11. 11. Filho feio não tem pai!
    12. 12. Afinal, de quem é a culpa?
    13. 13. É nossa!
    14. 14. Como mensurar a qualidade de um código?
    15. 15. OK! Vamos ao que interessa
    16. 16. NOMES SIGNIFICATIVOS
    17. 17. Nomes significativos int d; // tempo transcorrido em dias int tempoTranscorridoEmDias; int diasDesdeCriacaoDoArquivo; int diasDesdeModificacaoDoArquivo; int idadeDoArquivoEmDias;
    18. 18. Use nomes que revelem a intenção
    19. 19. Nomes significativos public List<int> obter() { int[] x = new int[3]; List<int> lista1 = new List<int>(); for (int i = 0; i < lista; i++) { if (x[0] == 4) { lista1.Add(x[0]); } } return lista1; } public List<int> obtemDiasMarcados() { int[] diaMarcado = new int[3]; List<int> diasMarcados = new List<int>(); for (int dia = 0; dia < mes; dia++) { if (diaMarcado[STATUS] == MARCADO) { diasMarcados.Add(diaMarcado[STATUS]); } } return diasMarcados; }
    20. 20. 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; }
    21. 21. Use nomes pronunciáveis
    22. 22. 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"; }
    23. 23. Use nomes buscáveis
    24. 24. Nomes significativos 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; } for (int j = 0; j < 30; j++) { s = (t[j]*4)/5; }
    25. 25. Nomeando classes e métodos
    26. 26. Nomes significativos Classes representadas por substantivos ex: Cliente, Perfil, Estoque, etc Métodos representadas por verbos ou frases verbais ex: enviarPagamento, salvar, etc.
    27. 27. FUNÇÕES
    28. 28. Seja pequeno
    29. 29. Funções • Menos é mais! • Extraia trechos em métodos privados. • Lembre-se dos nomes significativos • Vá direto ao ponto.
    30. 30. Funções
    31. 31. Faça uma coisa só!
    32. 32. 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.
    33. 33. Leia o código de cima pra baixo
    34. 34. 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;
    35. 35. Funções • Muitos argumentos = code smell • Existem algumas regras para a quantidade de argumentos • Argumentos booleanos, em geral, não são bons.
    36. 36. Funções
    37. 37. DRY (Don’t Repeat Yourself)
    38. 38. COMENTÁRIOS
    39. 39. Comentários não ajudam um código sujo!
    40. 40. 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!
    41. 41. Comentários aceitáveis
    42. 42. 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
    43. 43. Comentários ruins
    44. 44. 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
    45. 45. Comentários
    46. 46. FORMATAÇÃO
    47. 47. O que vale é a regra do time
    48. 48. OBJETOS E ESTRUTURA DE DADOS
    49. 49. Abstração de dados
    50. 50. Objetos e estrutura de dados
    51. 51. Objetos e estrutura de dados
    52. 52. A lei de Demeter
    53. 53. 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
    54. 54. Demeter Law C M
    55. 55. TRATAMENTO DE ERRO
    56. 56. Exceções ao invés de código de erro.
    57. 57. Tratamento de erro
    58. 58. Tratamento de erro
    59. 59. Tratamento de exceção é uma das coisas que um método ou função faz
    60. 60. Não use exceções genéricas
    61. 61. Não retorne null
    62. 62. Tratamento de erro • Obriga o uso de if • Pode disparar NullPointerException • Considere: Lançar exceção ou retornar um objeto especial
    63. 63. Não passe null
    64. 64. REGRA DOS ESCOTEIROS Deixe a área do acampamento mais limpa do que como você a Encontrou.
    65. 65. Não deixe acumular problemas!
    66. 66. 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.
    67. 67. Falar é fácil! O desafio é criar um código de qualidade. Portanto, falar é o primeiro passo de melhoria.
    68. 68. 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
    69. 69. END contato@rodrigokono.net

    ×