elseBlocco esplicito
Non sono d'accordo con questo come un'affermazione generale che copre tutte le ifaffermazioni, ma ci sono momenti in cui l'aggiunta di un elseblocco per abitudine è una buona cosa.
Una ifdichiarazione, a mio avviso, in realtà si estende su due funzioni distinte.
Se dovremmo fare qualcosa, fallo qui.
Roba del genere ovviamente non ha bisogno di una elseparte.
if (customer.hasCataracts()) {
appointmentSuggestions.add(new CataractAppointment(customer));
}
if (customer.isDiabetic()) {
customer.assignNurse(DiabeticNurses.pickBestFor(customer));
}
e in alcuni casi insistendo sull'aggiunta di un elsepotrebbe fuorviare.
if (k > n) {
return BigInteger.ZERO;
}
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
non è lo stesso di
if (k > n) {
return BigInteger.ZERO;
} else {
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
}
anche se funzionalmente è lo stesso. Scrivere il primo ifcon un vuoto elsepuò portare al secondo risultato che è inutilmente brutto.
Se stiamo verificando uno stato specifico, spesso è una buona idea aggiungere un vuoto elsesolo per ricordarti di coprire quella eventualità
// 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;
}
}
Ricorda che queste regole si applicano solo quando scrivi un nuovo codice . IMHO Le elseclausole vuote devono essere rimosse prima del check-in.
Prova per true, non perfalse
Anche in questo caso si tratta di buoni consigli a livello generale, ma in molti casi ciò rende il codice inutilmente complesso e meno leggibile.
Anche se il codice piace
if(!customer.canBuyAlcohol()) {
// ...
}
è stonante per il lettore, ma ce la fa
if(customer.canBuyAlcohol()) {
// Do nothing.
} else {
// ...
}
è almeno altrettanto male, se non peggio.
Ho codificato in BCPL molti anni fa e in quella lingua c'è una IFclausola e una UNLESSclausola in modo che tu possa codificare molto più facilmente come:
unless(customer.canBuyAlcohol()) {
// ...
}
che è significativamente migliore, ma ancora non perfetto.
Il mio processo personale
In genere, quando scrivo un nuovo codice, spesso aggiungo un elseblocco vuoto a ifun'istruzione solo per ricordarmi che non ho ancora coperto tale eventualità. Questo mi aiuta a evitare la DFStrappola e assicura che quando rivedo il codice noto che c'è ancora molto da fare. Tuttavia, di solito aggiungo un TODOcommento per tenere traccia.
if (returnVal == JFileChooser.APPROVE_OPTION) {
handleFileChosen();
} else {
// TODO: Handle case where they pressed Cancel.
}
Trovo che generalmente uso elseraramente nel mio codice in quanto spesso può indicare un odore di codice.