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.