O documento discute princípios de Clean Code e boas práticas de programação, destacando a importância de: 1) Dar nomes significativos às variáveis, métodos e classes; 2) Manter métodos pequenos e focados em uma única tarefa; 3) Escrever código de forma limpa e legível através da formatação e organização; 4) Criar objetos e classes coesas seguindo princípios como SRP.

1. CLEAN CODEpor Robert c. martin

2. O qUEsentimos quando encontramos código ruim?dortempo gastodecepçãofrustraçãoincerteza

3. O que é Código limpo?Uma coisasem duplicidadecuidadosimplesdiretoeficienteelegante

4. MeaningfulnamesNós escolhemos nomes para tudo. Então nós temos que fazer isto bem feito.O nome deve nos dizer: Por que ele existe.

5. O que ele faz.

6. Como ele é usado.MeaningfulnamesUse nomes que revelem sua intençãoint d; //daysSe um nome requer um comentário, quer dizer que ele não está revelando sua intenção.

7. MeaningfulnamesEvite desinformaçãoEvite palavras que podem ser variáveis ou palavras reservadas de outrasplataformas.

8. Evite dar nomes como “listaDeContas” (com o tipo no nome)- Evite usar ´L´ minusculo ou ´o´ maiusculo, eles parecem com 1 e 0.

9. MeaningfulnamesFaça distinções significativasUse nomes diferentesdentro de um mesmoescopo. for(int i = 0; i < a1.length; i++) { a2[i] = a1[i]; }

10. MeaningfulnamesUse nomes pronunciáveisEvite usar palavras que nãosão palavras.private Date genymdhms;Aoinvés de..private Date generationTimestamp;

11. MeaningfulnamesUse nomes fáceis de procurarNomes com apenasumaletraounuméricossãodificeis de ser encontrados e entendidosdentro do código.for (int j=0; j<34; j++) { s += (t[j]*4)/5;}

12. MeaningfulnamesQuando há sobrecarga do construtor, tente usar métodos estáticos que descrevem os parâmetros. Por exemplo: Complex fulcrumPoint = new Complex(23.0);Pode ser assim.. Complex fulcrumPoint = Complex.FromRealNumber(23.0);

13. MeaningfulnamesNão use trocadilhosEscrevaexatamente o quevocê quer dizer.

14. Não use palavrasapenaspor “consistência”.Porexemplo, não use “add” se nãoestárealmenteadicionandoalgo.

15. MeaningfulnamesBoas práticas- Nomes de classes devem ser substantivos e nunca devem conter verbos. Nomes de métodos devem conter verbos. Os mutators e accessors devem ser nomeados com os prefixos “get” e “set” de acordo com o padrão javabean.

16. functions O que faz uma método fácil de ler e entender?

17. Como podemos fazer com que um método transmita sua intenção?

18. Que atributos podemos passar para nossos métodos que permitam que um leitor saiba o que se passa dentro dele ?Métodos e funções são a primeira linha de organização de qualquer programa.

19. functionsPequenosA primeiraregra dos métodos e funções é queelesdevem ser pequenos.A segundaregra, é queelesdevem ser menoresainda.Devemsempreconteraté 20 linhas.- Linhasnãodevemcontermaisque 100 caracteres.- Seunível de identaçãonãodeve ser maiorquedois, o quefaz ser maisfácil de entender.

20. functionsFazer UMA coisa“Métodos e funçõesdevemfazerapenasumacoisa, devemfazê-la certa e devemsomentefazê-la.”É difícil saber o que é “umacoisa”.Tentarextrairoutrométodo de um primeiro com o nomedizendo o queeleestáfazendo.

21. functionsUse nomes clarosUse váriaspalavrasparaque o métodosejafacilmenteentendido e possa dizer o queelerealmentefaz.

22. functionsParâmetrosO número ideal de parâmetros de um métodooufunção é zero. Depoisvem um e dois.Trêsdeve ser evitado. Mais do quetrêsdeveteruma boa justificativaparatê-lo, poisnãodevem ser usados.

23. functionsParâmetros do tipo booleanPassar um booleanparaumafunção é umaterrívelprática.Issocomplica a assinatura do método.- Claramenteestádizendoque a funçãofazmais de umacoisa.

24. functionsEfeitos colateraisEfeitoscolateraissãomentiras.Suafunçãodizquefaráumacoisa, masfazoutras “escondidas”.publicbooleancheckPassword(String username, String password) { String passwordStatus = cryptographer.decrypt(password);if(passwordStatus.equals(“OK”)) {Session.initialize();returntrue; } returnfalse;}

25. functionsCommandqueryseparationMétodosdevemfazeralgumacoisaouretornaralgumacoisa. Masnãoosdois, poisissogeraconfusão.Don´t repeatyourselfPresteatenção no códigorepetido. Eviteduplicidade.

26. COMmentS- Comentáriospodem ser bastanteúteis se colocadosnoslugarescertos.- Podem ser mentirosos e trazerdesinformação, mesmosemintenção.Nãorecebem “manutenção”.- Apenas o códigopode dizer o queelerealmentefaz!

27. COMmentSComments do notmakeup for badcodeUm dos motivosmaiscomunspara se escrevercomentários é códigoruim.Entãoquandovocêpensaremescrever um comentário, é sinalqueeledeve ser refatorado.

28. COMmentSExplainyourself in code// Check if the employee is eligible for benefitsif((employee.flags==100) && (employee.age > 65))Ou issoif(employee.isEligibleForBenefits())

29. COMmentSGoodcomments: Alguns comentários são necessários ou benéficos. Mas o melhor é o que você não precisa escrever.Explanationofintent: Outros fornecem a intenção portrás de uma decisão tomada, e não só pela informação.Warningofconsequences: As vezes é útil avisar outros desenvolvedores sobre algumas consequências.

30. COMmentSBadcomments: “Qualquer comentário que força você a olhar em outra parte do código para entende-lo, não vale os bits que consome.” Redundantcomments: Não diz nada a mais que o próprioCódigo.Misleadingcomments: Quando um desenvolvedor declaraalgo e seu comentário que não é preciso o bastante para ser exato.Noisecomments: Declaram o óbvio.

31. COMmentSNão use comentários quando você pode usar métodos ou variáveis.// does the module from list depend on the // system we are part of?if(smodule.getDependSystems().contains(subSysMod.getSystem()))Use assim...ArrayListmoduleDependees = smodule.getDependSystems(); String ourSystem = subSysMod.getSystem(); if (moduleDependees.contains(ourSystem))

32. COMmentSClosingbracecommentstry{ String nada; while(i=3) {i++; ... ... } // end while } // end try

33. COMmentSCódigo comentadoNunca faça isso!!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.Inobvious connectionQuando um comentário precisa ser explicado.

34. FormattingFormatação é importante, pois se trata de comunicação.E comunicação é a primeira ordem para os desenvolvedores profissionais.A legibilidade do seu código terá profundo efeito em todas as mudanças que serão feitas.Seu estilo e disciplina sobrevive mesmo se o código original for alterado.

35. FormattingVertical formatingNão é uma regra, mas geralmente uma classe tem 200 linhas, com um limite de 500 linhas.Classes menores são mais fáceis de entender.Vertical distanceandorderingConceitos que estão relacionados devem ficar verticalmente próximos uns dos outros.

36. FormattingHorizontal formatingAlguns desenvolvedores sugerem um limite de 120 caracteres em uma linha.IdentaçãoUma boa identação do código ajuda a visualizar todo o escopo. Identificar as situações e regras relevantes mais rápido.

37. FormattingSempre use espaços entre operadores, parâmetros e vírgulas.public double(inta,intb,int c) { Double sum=number+(one*two);}Melhor assim...public double(int a, int b, int c) { Double sum = number + (one * two);}

38. Objectsand data structuresObjetos x Estrutura de dadosObjetos- Escondem os dados por abstração.- Expõem métodos que operam nos dados.Estrutura de dados- Expõem seus dados.- Não possuem métodos significativos.

39. Objectsand data structuresData abstractionpublic interface Vehicle { double getFuelTankCapacity(); double getGallonsOfGasoline();}Escondendo detalhes dos dados...public interface Vehicle { double getPercentFuelRemaining();}

40. ErrorhandlingTratar erros é umas das coisas que todos nós temos que fazer quando estamos programando.As coisas podem dar errado e nós temos que estar certos que nosso código fará o que deve fazer.

41. ErrorhandlingUse exceptions ratherthanreturncodesO problema desses retornos é que eles desorganizam a chamada.Quem fez a chamada deve verificar se há erros no retorno, e isso pode ser fácil de se esquecer.Por isso que é melhor lançar uma exception.

42. ErrorhandlingProvidecontextwith exceptions Crie mensagens informativas para os erros. Mencionando a operação que falhou e o tipo de falha.

43. ErrorhandlingDefina seu fluxoSepare as regras de negócio de erros ou outras situações.try {MealExpenses expenses = expensesDao.getMeals(); total += expenses.getTotal();} catch(MealExceptionNotFound e) { total += getMealPerDiem();}

44. ErrorhandlingDon´t returnnull: Evite retornar null em seus métodos. Prefira retornar SPECIAL CASE object ou vazio no caso de listas.List<Employees> employees = getEmployees();if(employees != null) { for(Employee employee : employees) { ... }}List<Employees> employees = getEmployees();for(Employee employee : employees) { ...}

45. ErrorhandlingDon´t passnullEvite passar null para seus métodos. Isso pode gerar as famosas NullPointerExceptions.

46. unittestsTestesGarantir que cada pedaço do código esteja fazendo o esperadoCriar mocks para os elementos com qual tenho o controle.Criar comandos para setar valores booleanos e garantir meu retorno quando aplicasse o valor correto.Uma vez passando, garantir que os testes serão úteis para qualquer um que trabalhar com esse código.

47. unittestsTrês Leis do TDDPrimeira: Vocênãopodeescrever o códigoatéquevocêtenhacriado um testefalhando.Segunda: Vocênãopodeescrevermais testes do quesejasuficienteparafalhar.Terceira: Vocênãopodeescrevermaiscódigo do que o suficienteparapassar o testequeestáfalhando.

48. unittestsMantenhaseus testes limpos O testeprecisasofreralteraçõesdamesma forma que o código.

49. Quantomaissujo o testemaisdificil de darmanutenção.- Se vocênãomantê-los limpos, vocêiráperdê-los. E semelesvocêperderá o quedeixaseucódigo de produçãoflexível.“O código do teste é tãoimportantequanto o códigodaprodução.”

50. unittestsTestes limpos O quefaz um teste ser limpo? A Legibilidade do código. O quefaz um teste ser legível? O mesmoquefaztodocódigolegível:Clareza

51. Simplicidade

52. CódigoexpressivounittestsUm conceitoportesteSepare um testequeestejatestandomais de um conceitoemoutros testes.

53. Facilite o entendimento de cadateste.unittestsF.I.R.S.T.Fast: Os Testes devem ser rápidos, poisquandosão lentos paraexecutar, vocênãovaiquererexecuta-los frequentemente, e assimvocênãovaiencontrar bugs cedo o suficientepararesolvê-los facilmente.Independent: Testes nãopodemdependeruns dos outros, pois se um falhaissoirácausar um efeitocascata de falhas.

54. unittestsF.I.R.S.T.Repeatable: Devem ser repetitivos, estardisponíveispararoda-los emqualquerambiente.Self-Validating: Elesdevempossuirumarespostabooleana. Semprecisarleroucompararresultadospara saber se o testepassou.Timely: O testedeve ser escrito um pouco antes do código. Apósele, serámaisdificilparafazer o teste.

55. unittestsClean testsTestes são importantes para a saúde do sistema, preservam e mantém a flexibilidade, manutenabilidade e reusabilidade do código.“Se você deixar seus testes apodrecerem, seu código também apodrecerá”

56. classesOrganizaçãodaclasseSeguindoospadrões do Java, a classedeveriacomeçar com umalista de variáveis. public static constants

57. private static variables

58. private instance variables Publicfunctions vêm depois das variavéis.E os métodos privados chamados de um publico, logo após o mesmo, seguindo a “stepdownrule”.

59. classesClasses devem ser pequenasComo para os métodos, a regra é a mesma. Devem ser pequenos.Para saber se o tamanho da classe é o ideal, analisamos suas responsabilidades. Nomear a classe também ajuda a determinar o tamanho e a responsabilidade dela.

60. classesPrincípiodaúnicaresponsabilidade (SRP)O princípio da única responsabilidade diz que uma classe deve ter uma, e apenas uma razão para mudar.Ele nos dá definições de responsabilidade e uma diretriz para o tamanho de uma classe.Tentar identificar responsabilidades nos ajuda a melhorar nosso código e criar melhores abstrações.

61. classesPrincípiodaúnicaresponsabilidade (SRP)O SRP é um dos conceitos mais importantes em Orientação a objetos. Também um dos mais simples de entender e aderir.O problema é que muitos temem o número de pequenas classes que são criadas. Precisam navegar entre as classes

62. classesCoesão Classes devem conter poucas variáveis.

63. Cada método deve manipular uma ou mais variáveis.

64. Geralmente quanto mais variáveis um método manipula, mais coeso ele é para a classe.

65. Quando há coesão, significa que métodos e variáveis são co-dependentes.- Quando aparecem muitas variáveis que são usadas por alguns métodos, talvez seja uma classe mais coesa tentando sair de uma maior.

66. classesMantendoresultadoscoesosem classes pequenasQuando a classe perde coesão, reparta-a.Quando quebramos um método grande em menores podemos ter a oportunidade de separar em classes menores também, o que nos proporciona mais organização e transparência.

67. EmergenteE se houvessem quatro regras que você pudesse seguir para ajudá-lo a criar bons designs de código e estrutura sendo mais fácil de aplicar princípios como SRP e DIP, e assim facilitar a criação de um de bom design de software.Pois aqui estão as 4 regras de Simple Design de Kent Beck: - Rode todos os testes; - Remova duplicação; - Expresse sua intenção; - Diminua o número de classes e métodos.

68. EmergenteRode todosos testesFazendo um sistema testável nos obriga e usar boas práticas como classes e métodos pequenos de apenas uma responsabilidade.Quanto mais testes fazermos, mais boas maneiras e princípios seguiremos para evitar o acoplamento de nosso código.Escrever testes nos leva a criar melhores designs.

69. EmergenteSemduplicaçãoDuplicação é o primeiro inimigo de um bom design. Ela representa trabalho e riscos adicionais e uma maior e desnecessária complexidade.Ela se manifesta em linhas de códigos iguais ou parecidas e também nas implementações.booleanisEmpty() {returnsize == 0; }booleanisEmpty() {}intgetSize() {}

70. EmergenteExpresse-seMuitos de nós já nos deparamos e produzimos código confuso. Expressar-se bem no código pode trazer grandes benefícios para o desenvolvimento de um sistema. Além de poupar tempo de quem o mantém.Você pode expressar bem escolhendo bons nomes, deixando métodos e classes pequenas, separando responsabilidades.Lembre-se que você pode sem o próximo a ler este código.

71. EmergenteMenos classes e métodosSempre que possível, nosso objetivo é manter nosso sistema pequeno enquanto ao mesmo tempo mantemos nossos métodos e classes pequenas.Essa é a última das quatro regras em questão de importância.

72. maus cheiros Comentários obsoletos e redundantes

73. Comentários pobres

74. Código comentado

75. Testes que requerem mais de um passo

76. Muitos parâmetros ou parâmetros boolean

77. Métodos mortos ou que fazem muita coisa.maus cheiros Duplicação

78. Inconsistência

79. Intenção obscura

80. Responsabilidades fora de contexto

81. Variáveis e funções inexpressivas

82. Despadronização

83. Números mágicosmaus cheiros Métodos fazendo mais de uma coisa

84. Desencapsulamento

85. Nomes pequenos e inexpressivos

86. Efeitos colaterais

87. Testes insuficientesConclusãoCleancode não foi escrito seguindo uma lista de regras.Você não se torna um bom programador aprendendo uma lista de regras. As técnicas e práticas têm que começar a fazer parte no nosso dia-a-dia. Devemos nos preocupar com a qualidade do código e não somente fazê-lo funcionar.

88. obrigado!