elseBloco explícito
Eu discordo disso como uma declaração geral que abrange todas as ifdeclarações, mas há momentos em que adicionar um elsebloqueio ao hábito é uma coisa boa.
Uma ifafirmação, na minha opinião, abrange duas funções distintas.
Se devemos fazer algo, faça-o aqui.
Obviamente, coisas assim não precisam de uma elseparte.
if (customer.hasCataracts()) {
appointmentSuggestions.add(new CataractAppointment(customer));
}
if (customer.isDiabetic()) {
customer.assignNurse(DiabeticNurses.pickBestFor(customer));
}
e, em alguns casos, insistir em adicionar um elsepode enganar.
if (k > n) {
return BigInteger.ZERO;
}
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
não é o mesmo que
if (k > n) {
return BigInteger.ZERO;
} else {
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
}
mesmo que seja funcionalmente o mesmo. Escrever o primeiro ifcom um vazio elsepode levar ao segundo resultado desnecessariamente feio.
Se estamos verificando um estado específico, geralmente é uma boa ideia adicionar um vazio elseapenas para lembrá-lo de que essa eventualidade
// Count wins/losses.
if (doors[firstChoice] == Prize.Car) {
// We would have won without switching!
winWhenNotSwitched += 1;
} else {
// We win if we switched to the car!
if (doors[secondChoice] == Prize.Car) {
// We picked right!
winWhenSwitched += 1;
} else {
// Bad choice.
lost += 1;
}
}
Lembre-se de que essas regras se aplicam somente quando você está escrevendo um novo código . IMHO As elsecláusulas vazias devem ser removidas antes do check-in.
Teste para true, não parafalse
Novamente, este é um bom conselho em nível geral, mas em muitos casos isso torna o código desnecessariamente complexo e menos legível.
Mesmo código como
if(!customer.canBuyAlcohol()) {
// ...
}
é chocante para o leitor, mas torná-lo
if(customer.canBuyAlcohol()) {
// Do nothing.
} else {
// ...
}
é pelo menos tão ruim, se não pior.
Eu codifiquei no BCPL há muitos anos e nesse idioma há uma IFcláusula e uma UNLESScláusula para que você possa codificar muito mais facilmente como:
unless(customer.canBuyAlcohol()) {
// ...
}
o que é significativamente melhor, mas ainda não é perfeito.
Meu processo pessoal
Geralmente, quando estou escrevendo um novo código, geralmente adiciono um elsebloco vazio a uma ifdeclaração apenas para lembrar que ainda não cobri essa eventualidade. Isso me ajuda a evitar a DFSarmadilha e garante que, ao revisar o código, observe que há mais a fazer. No entanto, costumo adicionar um TODOcomentário para acompanhar.
if (returnVal == JFileChooser.APPROVE_OPTION) {
handleFileChosen();
} else {
// TODO: Handle case where they pressed Cancel.
}
Acho que geralmente uso elseraramente no meu código, pois geralmente pode indicar um cheiro de código.