Código limpo 
CLEAN CODE(ROBERT C. MARTIN) 
YASSER V. DE ANDRADE
Nomes significativos 
Nós escolhemos nomes para tudo. Então nós temos que fazer isto bem 
feito. 
O nome deve nos dizer: 
...
Nomes significativos 
 Evite palavras que podem ser variáveis ou palavras reservadas de 
outras plataformas. 
 Evite dar...
Nomes significativos 
 Use nomes fáceis de procurar 
 Nomes com apenas uma letra ou números são difíceis de ser 
encontr...
Funções 
 O que faz uma método fácil de ler e entender? 
 Como podemos fazer com que um método transmita sua 
intenção? ...
Funções 
Pequenos 
 A primeira regra dos métodos e funções é que eles devem ser pequenos. 
 A segunda regra, é que eles ...
Funções 
Parâmetros 
 O número ideal de parâmetros de um método ou função é zero. 
Depois vem um e dois. 
 Três deve ser...
Funções 
Efeitos colaterais 
 Efeitos colaterais são mentiras. 
 Sua função dizque fará uma coisa, mas faz outras “escon...
Formatação 
Formatação é importante, pois se trata de comunicação. 
 Comunicação é a primeira ordem para os desenvolvedor...
Formatação 
Uma boa identação do código ajuda a visualizar todo o escopo. 
 Identificar as situações e regras relevantes ...
Comentários 
 Comentários podem ser bastante úteis se colocados nos lugares 
certos. 
 Podem ser mentirosos e trazer des...
Comentários 
 Explanationofintent: Outros fornecem a intenção por trás de uma 
decisão tomada, e não só pela informação. ...
Próximos SlideShares
Carregando em…5
×

Clean Code (Robert C. Martin)

480 visualizações

Publicada em

Uma apresentação sobre o resumo com alguns tópicos que eu particularmente achei importante sobre o livro Clean code.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
480
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Clean Code (Robert C. Martin)

  1. 1. Código limpo CLEAN CODE(ROBERT C. MARTIN) YASSER V. DE ANDRADE
  2. 2. Nomes significativos Nós escolhemos nomes para tudo. Então nós temos que fazer isto bem feito. O nome deve nos dizer:  Por que ele existe.  O que ele faz.  Como ele é usado. Use nomes que revelem sua intenção  int d; //days  Se um nome requer um comentário, quer dizer que ele não está revelando sua intenção.
  3. 3. Nomes significativos  Evite palavras que podem ser variáveis ou palavras reservadas de outras plataformas.  Evite dar nomes como “listaDePessoas”.  Evite usar ´L´ minúsculo ou ´o´ maiúsculo, eles parecem com 1 e 0.  Use nomes pronunciáveis. Evite usar palavras que não são palavras.  private String ndbofcli; Ao invés de..  private String nameDatabaseOfClient;
  4. 4. Nomes significativos  Use nomes fáceis de procurar  Nomes com apenas uma letra ou números são difíceis de ser encontrados e entendidos dentro do código.  Não use trocadilhos.  Escreva exatamente o que você quer dizer.  Não use palavras apenas por “consistência”.  Por exemplo, não use “add” se não está realmente adicionando algo.  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.
  5. 5. Funções  O que faz uma método fácil de ler e entender?  Como podemos fazer com que um método transmita sua intenção?  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.
  6. 6. Funções Pequenos  A primeira regra dos métodos e funções é que eles devem ser pequenos.  A segunda regra, é que eles devem ser menores ainda. Fazer UMA coisa  “Métodos e funções devem fazer apena uma coisa,  devem fazê-la certa e devem somente fazê-la.”  Tentar extrair outro método de um primeiro com o nome dizendo o que ele está fazendo.  Use nomes claros  Use várias palavras para que o método seja facilmente entendido e possa dizer o que ele realmente faz  Métodos devem fazer alguma coisa ou retornar alguma coisa. Mas não os dois, pois isso gera confusão.
  7. 7. Funções Parâmetros  O número ideal de parâmetros de um método ou função é zero. Depois vem um e dois.  Três deve ser evitado. Mais do que três deveter uma boa justificativa paratê-lo, pois não devem ser usados. Parâmetros do tipo boolean  Passar um boolean para uma função é uma terrível prática.  Isso complica a assinatura do método.  Claramente está dizendo que a função faz mais de uma coisa.
  8. 8. Funções Efeitos colaterais  Efeitos colaterais são mentiras.  Sua função dizque fará uma coisa, mas faz outras “escondidas”. public boolean checkPassword(String username, String password) { String passwordStatus = validate(password); if(passwordStatus.equals(“OK”)) { Session.initialize(); //initialize returntrue; } returnfalse; }
  9. 9. Formatação Formatação é importante, pois se trata de comunicação.  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.  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.
  10. 10. Formatação Uma boa identação do código ajuda a visualizar todo o escopo.  Identificar as situações e regras relevantes mais rápido.  Sempre use espaços entre operadores, parâmetros e vírgulas. public double(inta,intb,int c) { Double value=number+(123*2); }  Melhor assim... public double(int a, int b, int c) { Double value = number + (123 *2); }
  11. 11. Comentários  Comentários podem ser bastante úteis se colocados nos lugares certos.  Podem ser mentirosos e trazer desinformação, mesmo sem intenção.  Um dos motivos mais comuns para se escrever comentários é código ruim.  Então quando você pensar em escrever um comentário, é sinal que ele deve ser refatorado.  Goodcomments: Alguns comentários são necessários ou benéficos. Mas o melhor é o que você não precisa escrever.
  12. 12. Comentários  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.  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.

×