elseBloc explicite
Je ne suis pas d’accord avec cette affirmation en tant que déclaration générale couvrant toutes les ifdéclarations, mais il arrive que l’ajout d’un elsebloc par habitude soit une bonne chose.
Une ifdéclaration, à mon avis, recouvre en réalité deux fonctions distinctes.
Si nous sommes censés faire quelque chose, faites-le ici.
Ce genre de choses n'a évidemment pas besoin d'une elsepartie.
if (customer.hasCataracts()) {
appointmentSuggestions.add(new CataractAppointment(customer));
}
if (customer.isDiabetic()) {
customer.assignNurse(DiabeticNurses.pickBestFor(customer));
}
et dans certains cas insister pour ajouter un elsepourrait induire en erreur.
if (k > n) {
return BigInteger.ZERO;
}
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
n'est pas la même chose que
if (k > n) {
return BigInteger.ZERO;
} else {
if (k <= 0 || k == n) {
return BigInteger.ONE;
}
}
même si c'est fonctionnellement le même. Écrire le premier ifavec un vide elsepeut vous mener au deuxième résultat qui est inutilement laid.
Si nous recherchons un état spécifique, il est souvent judicieux d’ajouter un vide elseafin de vous rappeler de couvrir cette éventualité.
// 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;
}
}
N'oubliez pas que ces règles s'appliquent uniquement lorsque vous écrivez un nouveau code . IMHO Les elseclauses vides doivent être supprimées avant l'archivage.
Tester pour true, pas pourfalse
Là encore, c’est un bon conseil au niveau général, mais dans de nombreux cas, cela rend le code inutilement complexe et moins lisible.
Même si le code comme
if(!customer.canBuyAlcohol()) {
// ...
}
est choquant pour le lecteur, mais en le rendant
if(customer.canBuyAlcohol()) {
// Do nothing.
} else {
// ...
}
est au moins aussi mauvais, sinon pire.
J'ai codé dans BCPL il y a de nombreuses années et dans cette langue, il y a une IFclause et une UNLESSclause afin que vous puissiez coder beaucoup plus facilement comme suit:
unless(customer.canBuyAlcohol()) {
// ...
}
ce qui est nettement meilleur, mais toujours pas parfait.
Mon processus personnel
Généralement, lorsque j'écris un nouveau code, j'ajoute souvent un elsebloc vide à une ifdéclaration simplement pour me rappeler que je n'ai pas encore couvert cette éventualité. Cela m'aide à éviter le DFSpiège et à s'assurer que lorsque je relis le code, je constate qu'il reste encore beaucoup à faire. Cependant, j'ajoute généralement un TODOcommentaire pour garder une trace.
if (returnVal == JFileChooser.APPROVE_OPTION) {
handleFileChosen();
} else {
// TODO: Handle case where they pressed Cancel.
}
Je trouve que généralement j'utilise elserarement dans mon code car il peut souvent indiquer une odeur de code.