Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Código limpo

518 views

Published on

Esta apresentação tem como base o livro do clean code de Robert C. Martin.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Código limpo

  1. 1. Francisco Clauvane
  2. 2.  Esta apresentacao teve como base o livro Clean Code, a minha experiencia profissional e as dicas dadas por profissionais mais experientes. Onde o objetivo da mesma e mostrar na teoria e na pratica o que e um codigo limpo.
  3. 3.  1-Codigo limpo 2-Nomes significativos 3-Funcoes 4-Comentarios 5-Formatacao 6-Objetos e Estrutura de dados
  4. 4.  Codigo esta ultrapassado?  Modelos e requisitos  Codigo gerado e nao mais escrito Codigo ruim  Prazos curtos  Lei de LeBlanc: Mais tarde e igual a nunca. O custo de ter um codigo confuso  Mudanca alguma e trivial  Produtividade baixa;Adesao de novos membros  O grande replanejamento  Atitude: Assumindo a culpa  Gerentes: paixao ao prazos e requisitos;Programdores: paixao ao codigo
  5. 5.  A arte do codigo limpo  Analogia com a pintura de um quadro  Disciplina para aplicar pequenas tecnicas  Sensibilidade ao codigo O que e um codigo limpo?  Multiplas definicoes  Sensibilidade ao codigo  Grady Booch  Escolas de pensamento  Analogia ao estilo de uma arte marcial  A regra de escoteiro
  6. 6.  Nomeacoes constantes Use nomes que revelem seu proposito  int d;//Tempo decorrido em dias  int tempoDecorridoEmDias; Evite informacoes errradas  int hp;//hipotenusa  int[] accountList; Faca distincoes significativas  int a1,a2,a3;  getActiveAccount();  getActiveAccounts();  getActiveAccountInfo();
  7. 7.  Use nomes pronunciaveis  private Date genymdhms; Use nomes passiveis de busca  Nomes de uma letra so ou numeros possuem um problema em particular: nao sao faceis de encontrar ao longo de um texto;  O tamanho de uma variavel deve ser proporcional ao tamanho de seu escopo; Evite o mapeamento mental  Contador de interacoes ser chamado de ‘b’
  8. 8.  Nome de classes  Geralmente sao substantivos  Ex: Conta Nome de metodos  Geralmente sao nome de verbos  Ex: salvar  Acesso,alteracao e autenticacao  ‘get’, ‘set’ e ‘is’ Nao de uma de espertinho  Use nomes serios e nao obtidos a partir de brincadeiras que apenas um grupo limitado de pessoas saibam
  9. 9.  Uma palavra por conceito  Fetch,retrieve e get  Evite trocadilhos Use nomes a partir do dominio da solucao  accountVisitor  jobQueue  Na ausencia de nomes a partir da solucao use nomes a partir do problema. Adicione um contexto signigicativo  firstName/addrFirstName  Nao use contextos desnecessarios  PORTALAddrFirstName/addrFirstName
  10. 10.  Devem ser pequenas  Devem ser espertas Blocos e indentacoes  If,else e while devem possuir apenas uma linha  Estruras aninhadas devem possuir no maximo um ou dois niveis de indentacao Faca apenas uma coisa  Coesao: Principio da responsabilidade unica  Um nivel de abstracao por funcao  Regra decrescente
  11. 11.  Use nomes descritivos  Melhor um nome extenso do que um pequeno e enigmatico Parametros de funcoes  Requerem muito conceito  Ideal: sem parametros  Monades,diades,triades e poliades Parametros logicos  “Feios”: Ferem o principio da responsabilidade unica  Alternativa: Devem ser feitas duas funcoes, uma para cada valor logico
  12. 12.  Objetos como parametros  Circle makeCircle (double x, double y, double radius);  Circle makeCircle (Point center, double radius); Separacao comando consulta  As funcoes devem fazer ou responder algo, mas nao ambos  if(set(“username”, “clauvane”));  if (setAndCheckIfExists(“username”, “clauvane”)) ; Prefira excecoes a retorno de codigo de errro Extraia os blocos try/catch  Nao suba as excecoes para as camadas superiores, ao inves disto extraia os blocos try/catch dentro da propria funcao Tratamento de erro e uma coisa so  Nao deve existir codigo depois que o bloco try/catch termina
  13. 13.  Evite repeticoes  Duas ou mais funcoes que se utilizam de um mesmo trecho de codigo Programacao estrutura  Regra de Edsger Dijkstra: Cada funcao e bloco dentro de uma funcao deve ter uma entrada e uma saida.  Somente um return, nenhum break, continue e jamais um GOTO Como escrever funcoes como essa?  Segundo Robert C. Martin: “Nao aplico desde o comeco.Acho que isso nao seja possivel”
  14. 14.  Comentarios compensam um codigo ruim  Motivacao para fazer a bagunca  Explique-se no codigo Comentarios bons  De maneira geral, comentario bom e aquele que nao precisa ser escrito  Gerados automaticamente  Informativos  Explicacao da intencao  Alerta sobre consequencias  //TODO  Destaque  Javadocs
  15. 15.  Comentario ruins  Redundantes  Enganadores  Imperativos  Toda funcao deve ter um javadoc.  Longos  Ruidosos (Obvios) Evite o comentario se e possivel usar uma funcao ou variavel Marcadores de posicao  Se usados esporadicamente e em situacoes que seja justificado sua existencia (sensibilidade ao codigo) nao ha problemas
  16. 16.  Comentarios ao lado de chaves de fechamento  Usado em funcoes grandes  Ao inves de usar um comentario para suprir a necessidade de compreensao da funcao, voce deve diminuir esta funcao Credito e autoria  Desnecessarios  Versionamento de codigo Codigo como comentario  Medo  Versionamento de codigo Comentario HTML  Tarefa da ferramenta e nao do programador
  17. 17.  Informacoes nao-locais  Comentario devem estar proximos ao codigo que e descrito Informacoes excessivas Conexoes com o codigo  O comentario deve esta conectado ao codigo o suficiente para que o proximo leitor seja capaz de entende-lo Cabecalhos de funcoes  Melhor usar um bom nome do que um comentario de cabecalho Javadoc em codigos nao-publicos  Diferentemente dos codigo publicos os javadoc dos nao- publicos sao horriveis
  18. 18.  Objetivo da formatacao  Comunicao de qualidade entre os programadores Vertical  Tamanho da classe em linhas  Metafora do jornal  Nivel de abstracao vai do topo para baixo Espacamento vertical entre os conceitos  Uma linha em branco Distancia vertical  Os conceitos intimamentes ligados devem ficar juntos verticalmente  Declaracao de variaveis,variaveis de instancia,funcoes dependentes  Afinidade conceitual  Ordenacao vertical  A funcao chamada deve ficar abaixo da que a chama
  19. 19.  Horizontal  Tamanho da linha  Espacamento e continuidade horizontal  Um espaco em branco Alinhamento Horizontal  Nao e pratico Indentacao  No maximo uma ou duas
  20. 20.  Abstracao de dados  Concreto  Estrutura de dados  Abstrato  Objeto A lei de Demeter  Um modulo nao deve enxergar o interior de um objeto que ele manipula. Train wrecks (Acidentes ferroviarios)  String coisa = getCoisa().getAlgumaCoisa().getOutraCoisa();  Violacao a lei de Demeter Hibridos  Metade Objeto metade estrutura de dados Objetos de transferencia de dados (DTOs)  beans
  21. 21.  Active record  DTOs com metodos de navegacao  Sao estrutura de dados  Muitos o tratam como objeto e acabam o tornando num hibrido
  22. 22.  Sites e livros recomendados  http://www.guj.com.br  http://www.CasaDoCodigo.com.br  http://www.caelum.com.br/online  https://github.com/clauvane  https://github.com/rponte  O livro Clean Code de Robert C. Martin

×