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

1. Código limpo
CLEAN CODE(ROBERT C. MARTIN)
YASSER V. DE ANDRADE

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