Clean Code

11,178 views

Published on

Apresentação sobre o livro Clean Code de Robert C. Martin.
Algumas técnicas e boas práticas para identificar e melhorar nosso código.

Segue o link para o artigo: http://bluesoft.wordpress.com/2010/05/06/bluesoft-labs-clean-code-por-bruno-lui/

Published in: Technology, Self Improvement
5 Comments
40 Likes
Statistics
Notes
No Downloads
Views
Total views
11,178
On SlideShare
0
From Embeds
0
Number of Embeds
638
Actions
Shares
0
Downloads
0
Comments
5
Likes
40
Embeds 0
No embeds

No notes for slide

Clean Code

  1. 1. CLEAN CODEpor Robert c. martin<br />
  2. 2. O sentimos quando encontramos código ruim?<br />dor<br />tempo gasto<br />decepção<br />frustração<br />incerteza<br />
  3. 3. O que é Código limpo?<br />Uma coisa<br />sem duplicidade<br />cuidado<br />simples<br />direto<br />eficiente<br />elegante<br />
  4. 4. Meaningfulnames<br />Nós escolhemos nomes para tudo. <br />Então nós temos que fazer isto bem feito.<br />O nome deve nos dizer:<br /><ul><li> Por que ele existe.
  5. 5. O que ele faz.
  6. 6. Como ele é usado.</li></li></ul><li>Meaningfulnames<br />Use nomes que revelem sua intenção<br />int d; //days<br />Se um nome requer um comentário, quer dizer que ele não está revelando sua intenção.<br />
  7. 7. Meaningfulnames<br />Evite desinformação<br /><ul><li>Evite palavras que podem ser variáveis ou palavras reservadas de outrasplataformas.    
  8. 8. Evite dar nomes como “listaDeContas” (com o tipo no nome)</li></ul>- Evite usar ´L´ minusculo ou ´o´ maiusculo, eles parecem com 1 e 0.<br />
  9. 9. Meaningfulnames<br />Faça distinções significativas<br /><ul><li>Use nomes diferentesdentro de um mesmoescopo.    </li></ul>for(int i = 0; i &lt; a1.length; i++) {<br /> a2[i] = a1[i];    <br />}<br />
  10. 10. Meaningfulnames<br />Use nomes pronunciáveis<br /><ul><li>Evite usar palavras que nãosão palavras.</li></ul>private Date genymdhms;<br />Aoinvés de..<br />private Date generationTimestamp;<br />
  11. 11. Meaningfulnames<br />Use nomes fáceis de procurar<br /><ul><li>Nomes com apenasumaletraounuméricossãodificeis de ser encontrados e entendidosdentro do código.</li></ul>for (int j=0; j&lt;34; j++) {<br /> s += (t[j]*4)/5;<br />}<br />
  12. 12. Meaningfulnames<br />Quando há sobrecarga do construtor, tente usar métodos estáticos que descrevem os parâmetros. Por exemplo:<br /> Complex fulcrumPoint = new Complex(23.0);<br />Pode ser assim..<br /> Complex fulcrumPoint = Complex.FromRealNumber(23.0);<br />
  13. 13. Meaningfulnames<br />Não use trocadilhos<br /><ul><li>Escrevaexatamente o quevocê quer dizer.
  14. 14. Não use palavrasapenaspor “consistência”.</li></ul>Porexemplo, não use “add” se nãoestárealmenteadicionandoalgo.<br />
  15. 15. Meaningfulnames<br />Boas práticas<br />- Nomes de classes devem ser substantivos e nunca devem conter verbos.<br /><ul><li> Nomes de métodos devem conter verbos. </li></ul> Os mutators e accessors devem ser nomeados com os prefixos “get” e “set” de acordo com o padrão javabean.<br />
  16. 16. functions<br /><ul><li> O que faz uma método fácil de ler e entender?
  17. 17. Como podemos fazer com que um método transmita sua intenção?
  18. 18. Que atributos podemos passar para nossos métodos que permitam que um leitor saiba o que se passa dentro dele ?</li></ul>Métodos e funções são a primeira linha de organização de qualquer programa.<br />
  19. 19. functions<br />Pequenos<br />A primeiraregra dos métodos e funções é queelesdevem ser pequenos.<br />A segundaregra, é queelesdevem ser menoresainda.<br /><ul><li>Devemsempreconteraté 20 linhas.</li></ul>- Linhasnãodevemcontermaisque 100 caracteres.<br />- Seunível de identaçãonãodeve ser maiorquedois, o quefaz ser maisfácil de entender.<br />
  20. 20. functions<br />Fazer UMA coisa<br />“Métodos e funçõesdevemfazerapenasumacoisa, <br />devemfazê-la certa e devemsomentefazê-la.”<br />É difícil saber o que é “umacoisa”.<br />Tentarextrairoutrométodo de um primeiro com o nomedizendo o queeleestáfazendo. <br />
  21. 21. functions<br />Use nomes claros<br />Use váriaspalavrasparaque o métodosejafacilmenteentendido e possa dizer o queelerealmentefaz.<br />
  22. 22. functions<br />Parâmetros<br />O número ideal de parâmetros de um métodooufunção é zero. Depoisvem um e dois.<br />Trêsdeve ser evitado. Mais do quetrêsdeveteruma boa justificativaparatê-lo, poisnãodevem ser usados.<br />
  23. 23. functions<br />Parâmetros do tipo boolean<br />Passar um booleanparaumafunção é umaterrívelprática.<br /><ul><li>Issocomplica a assinatura do método.</li></ul>- Claramenteestádizendoque a funçãofazmais de umacoisa.<br />
  24. 24. functions<br />Efeitos colaterais<br />Efeitoscolateraissãomentiras.<br />Suafunçãodizquefaráumacoisa, masfazoutras “escondidas”.<br />publicbooleancheckPassword(String username, String password) {<br /> String passwordStatus = cryptographer.decrypt(password);<br />if(passwordStatus.equals(“OK”)) {<br />Session.initialize();<br />returntrue;<br /> } <br />returnfalse;<br />}<br />
  25. 25. functions<br />Commandqueryseparation<br />Métodosdevemfazeralgumacoisaouretornaralgumacoisa. Masnãoosdois, poisissogeraconfusão.<br />Don´t repeatyourself<br />Presteatenção no códigorepetido. Eviteduplicidade.<br />
  26. 26. COMmentS<br />- Comentáriospodem ser bastanteúteis se colocadosnoslugarescertos.<br />- Podem ser mentirosos e trazerdesinformação, mesmosemintenção.<br /><ul><li>Nãorecebem “manutenção”.</li></ul>- Apenas o códigopode dizer o queelerealmentefaz! <br />
  27. 27. COMmentS<br />Comments do notmakeup for badcode<br />Um dos motivosmaiscomunspara se escrevercomentários é códigoruim.<br />Entãoquandovocêpensaremescrever um comentário, é sinalqueeledeve ser refatorado.<br />
  28. 28. COMmentS<br />Explainyourself in code<br />// Check if the employee is eligible for benefits<br />if((employee.flags==100) && (employee.age &gt; 65))<br />Ou isso<br />if(employee.isEligibleForBenefits())<br />
  29. 29. COMmentS<br />Goodcomments: Alguns comentários são necessários <br />ou benéficos. Mas o melhor é o que você não precisa escrever.<br />Explanationofintent: Outros fornecem a intenção por<br />trás de uma decisão tomada, e não só pela informação.<br />Warningofconsequences: As vezes é útil avisar outros <br />desenvolvedores sobre algumas consequências.<br />
  30. 30. COMmentS<br />Badcomments: “Qualquer comentário que força você <br />a olhar em outra parte do código para entende-lo, <br />não vale os bits que consome.” <br />Redundantcomments: Não diz nada a mais que o próprio<br />Código.<br />Misleadingcomments: Quando um desenvolvedor declara<br />algo e seu comentário que não é preciso o bastante para <br />ser exato.<br />Noisecomments: Declaram o óbvio.<br />
  31. 31. COMmentS<br />Não use comentários quando você pode usar métodos ou variáveis.<br />// does the module from list depend on the <br />// system we are part of?<br />if(smodule.getDependSystems().contains(subSysMod.getSystem()))<br />Use assim...<br />ArrayListmoduleDependees = smodule.getDependSystems();<br /> String ourSystem = subSysMod.getSystem();<br /> if (moduleDependees.contains(ourSystem)) <br />
  32. 32. COMmentS<br />Closingbracecomments<br />try{<br /> String nada; while(i=3) {i++; <br /> ...<br /> ... } // end while<br /> } // end try<br />
  33. 33. COMmentS<br />Código comentado<br />Nunca faça isso!!<br />Quando alguém vê um código comentado, não tem a coragem de apagá-lo. Vão pensar que há uma razão para estar ali.<br />Inobvious connection<br />Quando um comentário precisa ser explicado.<br />
  34. 34. Formatting<br />Formatação é importante, pois se trata de comunicação.<br />E comunicação é a primeira ordem para os desenvolvedores profissionais.<br />A legibilidade do seu código terá profundo efeito em todas as mudanças que serão feitas.<br />Seu estilo e disciplina sobrevive mesmo se o código original for alterado. <br />
  35. 35. Formatting<br />Vertical formating<br />Não é uma regra, mas geralmente uma classe tem 200 linhas, com um limite de 500 linhas.<br />Classes menores são mais fáceis de entender.<br />Vertical distanceandordering<br />Conceitos que estão relacionados devem ficar verticalmente próximos uns dos outros. <br />
  36. 36. Formatting<br />Horizontal formating<br />Alguns desenvolvedores sugerem um limite de 120 caracteres em uma linha.<br />Identação<br />Uma boa identação do código ajuda a visualizar todo o escopo. <br />Identificar as situações e regras relevantes mais rápido.<br />
  37. 37. Formatting<br />Sempre use espaços entre operadores, parâmetros e vírgulas.<br />public double(inta,intb,int c) {<br /> Double sum=number+(one*two);<br />}<br />Melhor assim...<br />public double(int a, int b, int c) {<br /> Double sum = number + (one * two);<br />}<br />
  38. 38. Objectsand data structures<br />Objetos x Estrutura de dados<br />Objetos<br />- Escondem os dados por abstração.<br />- Expõem métodos que operam nos dados.<br />Estrutura de dados<br />- Expõem seus dados.<br />- Não possuem métodos significativos.<br />
  39. 39. Objectsand data structures<br />Data abstraction<br />public interface Vehicle {<br /> double getFuelTankCapacity();<br /> double getGallonsOfGasoline();<br />}<br />Escondendo detalhes dos dados...<br />public interface Vehicle {<br /> double getPercentFuelRemaining();<br />}<br />
  40. 40. Errorhandling<br />Tratar erros é umas das coisas que todos nós temos que fazer quando estamos programando.<br />As coisas podem dar errado e nós temos que estar certos que nosso código fará o que deve fazer.<br />
  41. 41. Errorhandling<br />Use exceptions ratherthanreturncodes<br />O problema desses retornos é que eles desorganizam a chamada.<br />Quem fez a chamada deve verificar se há erros no retorno, e isso pode ser fácil de se esquecer.<br />Por isso que é melhor lançar uma exception.<br />
  42. 42. Errorhandling<br />Providecontextwith exceptions <br />Crie mensagens informativas para os erros. Mencionando a operação que falhou e o tipo de falha.<br />
  43. 43. Errorhandling<br />Defina seu fluxo<br />Separe as regras de negócio de erros ou outras situações.<br />try {<br />MealExpenses expenses = expensesDao.getMeals();<br /> total += expenses.getTotal();<br />} catch(MealExceptionNotFound e) {<br /> total += getMealPerDiem();<br />}<br />
  44. 44. Errorhandling<br />Don´t returnnull: Evite retornar null em seus métodos. Prefira retornar SPECIAL CASE object ou vazio no caso de listas.<br />List&lt;Employees&gt; employees = getEmployees();<br />if(employees != null) {<br /> for(Employee employee : employees) {<br /> ...<br /> }<br />}<br />List&lt;Employees&gt; employees = getEmployees();<br />for(Employee employee : employees) {<br /> ...<br />}<br />
  45. 45. Errorhandling<br />Don´t passnull<br />Evite passar null para seus métodos. Isso pode gerar as famosas NullPointerExceptions.<br />
  46. 46. Perguntas ?<br />
  47. 47. obrigado!<br />

×