Boas PráticasClean CodeTécnica para um código limpoRodrigo KonoMVP, MCTS, MCPD, MCT, MCP@rodrigokonowww.rodrigokono.net
Rodrigo Kono•   MVP Microsoft•   MCP – MCTS – MCPD – MCT•   Foco em desenvolvimento WEB•   Developer na LG Sistemas•   Fun...
E ao meu lado hoje...Frederico Maia Arantes• 5 anos de experiência em Desenvolvimento  de Software.• 3 anos de experiência...
Há duas razões pelas quaisvocê está nesta palestra:1. Você é um programador2. Deseja se tornar um ainda melhor.
ÓTIMO! PRECISAMOS DE  PROGRAMADORES     MELHORES C. Martin              Robert
The Clean CoderRobert C. Martin (Uncle Bob); Programador desde 1970;Fundador e Presidente Object Mentor Inc.Livros:Designi...
O que é Clean Code?
•   Eficiente•   Simples•   Direto ao ponto•   Mínimas    dependências•   Sem duplicação•   Fácil manutenção•   Padrões de...
Que porta representa o seu         código?
"Qualquer um consegue escrever   código que um computador entende. Bons programadores escrevem código que humanos         ...
Funcionar é o mínimo que se espera
Ah! Mas o cronograma éapertado.Não tenho tempo parafrescura!Meu chefe está mepressionando!Quero mostrarprodutividade.
Filho feio não tem pai!
Afinal, de quem é a culpa?
É nossa!
Como mensurar aqualidade de um código?
OK! Vamos ao que interessa
NOMESSIGNIFICATIVOS
Nomes significativos       int d;    // tempo transcorrido em dias       int   tempoTranscorridoEmDias;       int   diasDe...
Use nomes que revelem a       intenção
Nomes significativos public List<int> obter()                  public List<int> obtemDiasMarcados() {                     ...
Nomes significativos       public List<int> obtemDiasMarcados()       {           int[] diaMarcado = new int[3];          ...
Use nomespronunciáveis
Nomes significativos       class DtaRcrd102       {           private DateTime gerdmahms;           private DateTime moddm...
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...
Nomeando classes e métodos
Nomes significativosClasses     representadas por substantivos     ex: Cliente, Perfil, Estoque, etcMétodos     representa...
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...
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...
Funções• Muitos argumentos = code smell• Existem algumas regras para a  quantidade de argumentos• Argumentos booleanos, em...
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...
Comentários aceitáveis
Comentários• Comentários sobre licença (direitos  de uso de uma lib, por exemplo)• Comentários informativos• Necessidade d...
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...
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 dadosUm método F de uma classe C só conhece:•   Métodos de C•   Objetos criados por F•   Objetos pa...
TRATAMENTO DE ERRO
Exceções ao invés de   código de erro.
Tratamento de erro
Tratamento de erro
Tratamento de exceção é uma dascoisas 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 dispara NullPointerException• Considere: Lançar exceção ou retornar um objeto...
Não passe null
REGRA DOS ESCOTEIROSDeixe a área do acampamentomais limpa do que como você aEncontrou.
Não deixe acumular problemas!
Código ruimcheira mal...Torna o seutrabalho lento edesgastante com opassar do tempoPode arruinar seuprojeto, carreira,empr...
Falar é fácil!   O desafio é criar um código de             qualidade.    Portanto, falar é o primeiro passo de           ...
Using References;Gustavo Barbosahttp://www.slideshare.net/gustavocsbHendrik Ebelhttp://www.slideshare.net/hebelThiago Fari...
END
Boas práticas técnica para um código limpo (Clean Code)
Boas práticas técnica para um código limpo (Clean Code)
Upcoming SlideShare
Loading in...5
×

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

5,576

Published on

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.

Published in: Technology

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

  1. 1. Boas PráticasClean CodeTécnica para um código limpoRodrigo KonoMVP, MCTS, MCPD, MCT, MCP@rodrigokonowww.rodrigokono.net
  2. 2. Rodrigo Kono• MVP Microsoft• MCP – MCTS – MCPD – MCT• Foco em desenvolvimento WEB• Developer na LG Sistemas• Fundador do DevGoiás.NET• Dez anos de comunidade .NET• Palestrou em mais de 12 capitais• Mais de 14.500 pessoas nesse tempo• Finalista Imagine Cup 2005 – Brasil/Japão
  3. 3. E ao meu lado hoje...Frederico Maia Arantes• 5 anos de experiência em Desenvolvimento de Software.• 3 anos de experiência em Desenvolvimento Java.• 2 anos de experiência como instrutor de treinamentos.• Membro e coordenador do Grupo de Usuários Java de Goiás (Gojava)..
  4. 4. Há duas razões pelas quaisvocê está nesta palestra:1. Você é um programador2. Deseja se tornar um ainda melhor.
  5. 5. ÓTIMO! PRECISAMOS DE PROGRAMADORES MELHORES C. Martin Robert
  6. 6. The Clean CoderRobert 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.
  7. 7. O que é Clean Code?
  8. 8. • 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
  9. 9. Que porta representa o seu código?
  10. 10. "Qualquer um consegue escrever código que um computador entende. Bons programadores escrevem código que humanos endentem“ Martin Fowler
  11. 11. Funcionar é o mínimo que se espera
  12. 12. Ah! Mas o cronograma éapertado.Não tenho tempo parafrescura!Meu chefe está mepressionando!Quero mostrarprodutividade.
  13. 13. Filho feio não tem pai!
  14. 14. Afinal, de quem é a culpa?
  15. 15. É nossa!
  16. 16. Como mensurar aqualidade de um código?
  17. 17. OK! Vamos ao que interessa
  18. 18. NOMESSIGNIFICATIVOS
  19. 19. Nomes significativos int d; // tempo transcorrido em dias int tempoTranscorridoEmDias; int diasDesdeCriacaoDoArquivo; int diasDesdeModificacaoDoArquivo; int idadeDoArquivoEmDias;
  20. 20. Use nomes que revelem a intenção
  21. 21. 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; } }
  22. 22. 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; }
  23. 23. Use nomespronunciáveis
  24. 24. 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"; }
  25. 25. Use nomes buscáveis
  26. 26. 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; }
  27. 27. Nomeando classes e métodos
  28. 28. Nomes significativosClasses representadas por substantivos ex: Cliente, Perfil, Estoque, etcMétodos representadas por verbos ou frasesverbais ex: enviarPagamento, salvar, etc.
  29. 29. FUNÇÕES
  30. 30. Seja pequeno
  31. 31. Funções• Menos é mais!• Extraia trechos em métodos privados.• Lembre-se dos nomes significativos• Vá direto ao ponto.
  32. 32. Funções
  33. 33. Faça uma coisa só!
  34. 34. 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.
  35. 35. Leia o código de cima pra baixo
  36. 36. 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;
  37. 37. Funções• Muitos argumentos = code smell• Existem algumas regras para a quantidade de argumentos• Argumentos booleanos, em geral, não são bons.
  38. 38. Funções
  39. 39. DRY (Don’t Repeat Yourself)
  40. 40. COMENTÁRIOS
  41. 41. Comentários não ajudam um código sujo!
  42. 42. 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!
  43. 43. Comentários aceitáveis
  44. 44. 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
  45. 45. Comentários ruins
  46. 46. 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
  47. 47. Comentários
  48. 48. FORMATAÇÃO
  49. 49. O que vale é a regra do time
  50. 50. OBJETOS E ESTRUTURA DE DADOS
  51. 51. Abstração de dados
  52. 52. Objetos e estrutura de dados
  53. 53. Objetos e estrutura de dados
  54. 54. A lei de Demeter
  55. 55. Objetos e estrutura de dadosUm método F de uma classe C só conhece:• Métodos de C• Objetos criados por F• Objetos passados como argumentos para F• Objetos em variáveis de instâncias de C
  56. 56. TRATAMENTO DE ERRO
  57. 57. Exceções ao invés de código de erro.
  58. 58. Tratamento de erro
  59. 59. Tratamento de erro
  60. 60. Tratamento de exceção é uma dascoisas que um método ou função faz
  61. 61. Não use exceções genéricas
  62. 62. Não retorne null
  63. 63. Tratamento de erro• Obriga o uso de if• Pode dispara NullPointerException• Considere: Lançar exceção ou retornar um objeto especial
  64. 64. Não passe null
  65. 65. REGRA DOS ESCOTEIROSDeixe a área do acampamentomais limpa do que como você aEncontrou.
  66. 66. Não deixe acumular problemas!
  67. 67. Código ruimcheira mal...Torna o seutrabalho lento edesgastante com opassar do tempoPode arruinar seuprojeto, carreira,empresa...Fique atento.
  68. 68. Falar é fácil! O desafio é criar um código de qualidade. Portanto, falar é o primeiro passo de melhoria.
  69. 69. Using References;Gustavo Barbosahttp://www.slideshare.net/gustavocsbHendrik Ebelhttp://www.slideshare.net/hebelThiago Faria de Andradehttp://www.slideshare.net/thiagofa
  70. 70. END

×