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? dor tempo gasto decepção frustração incerteza

3. O que é Código limpo? Uma coisa sem duplicidade cuidado simples direto eficiente elegante

5. O que ele faz.

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

12. Meaningfulnames Quando 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);

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

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.

20. functions Fazer 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. functions Use nomes claros Use váriaspalavrasparaque o métodosejafacilmenteentendido e possa dizer o queelerealmentefaz.

22. functions Parâmetros O 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.

24. functions Efeitos colaterais Efeitoscolateraissã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. functions Commandqueryseparation Métodosdevemfazeralgumacoisaouretornaralgumacoisa. Masnãoosdois, poisissogeraconfusão. Don´t repeatyourself Presteatenção no códigorepetido. Eviteduplicidade.

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

28. COMmentS Explainyourself in code // Check if the employee is eligible for benefits if((employee.flags==100) && (employee.age > 65)) Ou isso if(employee.isEligibleForBenefits())

29. COMmentS Goodcomments: 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 por trá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. COMmentS Badcomments: “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óprio Código. Misleadingcomments: Quando um desenvolvedor declara algo e seu comentário que não é preciso o bastante para ser exato. Noisecomments: Declaram o óbvio.

31. COMmentS Nã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. COMmentS Closingbracecomments try{ String nada; while(i=3) {i++; ... ... } // end while } // end try

33. COMmentS Código comentado Nunca 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 connection Quando um comentário precisa ser explicado.

34. Formatting Formataçã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. Formatting Vertical formating Nã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 distanceandordering Conceitos que estão relacionados devem ficar verticalmente próximos uns dos outros.

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

37. Formatting Sempre 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 structures Objetos x Estrutura de dados Objetos - 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 structures Data abstraction public interface Vehicle { double getFuelTankCapacity(); double getGallonsOfGasoline(); } Escondendo detalhes dos dados... public interface Vehicle { double getPercentFuelRemaining(); }

40. Errorhandling Tratar 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. Errorhandling Use exceptions ratherthanreturncodes O 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. Errorhandling Providecontextwith exceptions Crie mensagens informativas para os erros. Mencionando a operação que falhou e o tipo de falha.

43. Errorhandling Defina seu fluxo Separe 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. Errorhandling Don´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. Errorhandling Don´t passnull Evite passar null para seus métodos. Isso pode gerar as famosas NullPointerExceptions.

46. unittests Testes Garantir que cada pedaço do código esteja fazendo o esperado Criar 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. unittests Três Leis do TDD Primeira: 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.

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.”

51. Simplicidade

54. unittests F.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. unittests Clean tests Testes 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á”

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. classes Classes devem ser pequenas Como 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. classes Princí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. classes Princí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

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. classes Mantendoresultadoscoesosem classes pequenas Quando 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. Emergente E 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. Emergente Rode todosos testes Fazendo 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. Emergente Semduplicação Duplicaçã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. Emergente Expresse-se Muitos 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. Emergente Menos classes e métodos Sempre 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.

73. Comentários pobres

74. Código comentado

75. Testes que requerem mais de um passo

76. Muitos parâmetros ou parâmetros boolean

78. Inconsistência

79. Intenção obscura

80. Responsabilidades fora de contexto

81. Variáveis e funções inexpressivas

82. Despadronização

84. Desencapsulamento

85. Nomes pequenos e inexpressivos

86. Efeitos colaterais

88. obrigado!