Blocco esplicito else
Non sono d'accordo con questo come una dichiarazione coperta che copre tutte le dichiarazioni if , ma ci sono momenti in cui l'aggiunta di un blocco else per abitudine è una buona cosa.
Un'istruzione if , a mio parere, copre in realtà due funzioni distinte.
Se dovessimo fare qualcosa, fallo qui.
Cose del genere ovviamente non richiedono una parte else .
if (customer.hasCataracts()) {
appointmentSuggestions.add(new CataractAppointment(customer));
}
if (customer.isDiabetic()) {
customer.assignNurse(DiabeticNurses.pickBestFor(customer));
}
e in alcuni casi insistere sull'aggiunta di else potrebbe indurre in errore.
if (k > n) {
return BigInteger.ZERO;
}
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
è non uguale a
if (k > n) {
return BigInteger.ZERO;
} else {
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
}
anche se è funzionalmente lo stesso. Scrivere il primo if con una else vuota può portare al secondo risultato che è inutilmente brutto.
Se stiamo verificando uno stato specifico, è spesso una buona idea aggiungere un else vuoto solo per ricordarti di coprire quell'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 nuovo codice . IMHO Le clausole else vuote devono essere rimosse prima del check-in.
Test per true , non per false
Anche in questo caso si tratta di un buon consiglio a livello generale, ma in molti casi ciò rende il codice inutilmente complesso e meno leggibile.
Anche se codice come
if(!customer.canBuyAlcohol()) {
// ...
}
è stridente per il lettore, ma lo rende
if(customer.canBuyAlcohol()) {
// Do nothing.
} else {
// ...
}
è almeno altrettanto brutto, se non peggio.
Ho codificato in BCPL molti anni fa e in quel linguaggio c'è una clausola IF e una clausola UNLESS in modo da poter codificare molto più facilmente come:
unless(customer.canBuyAlcohol()) {
// ...
}
che è significativamente migliore, ma non è ancora perfetto.
Il mio processo personale
In genere, quando scrivo il codice nuovo aggiungo spesso un blocco else vuoto a un'istruzione if solo per ricordarmi che non ho ancora coperto quell'eventualità. Questo mi aiuta a evitare la trappola DFS e assicura che quando riesame il codice, noto che c'è ancora molto da fare. Tuttavia, di solito aggiungo un commento di TODO per tenere traccia.
if (returnVal == JFileChooser.APPROVE_OPTION) {
handleFileChosen();
} else {
// TODO: Handle case where they pressed Cancel.
}
Trovo che generalmente io uso else raramente nel mio codice in quanto spesso può indicare un odore di codice.