Pourquoi "else" est-il rarement utilisé après "si x retourne"?

Question

Cette méthode:

boolean containsSmiley(String s) {
    if (s == null) {
        return false;
    }
    else {
        return s.contains(":)");
    }
}

peut être écrit de manière équivalente:

boolean containsSmiley(String s) {
    if (s == null) {
        return false;
    }

    return s.contains(":)");
}

Dans mon expérience, la deuxième forme est vu le plus souvent, en particulier dans les méthodes plus complexes (où il peut y avoir plusieurs points de sortie), et le même est vrai pour "jeter" et "retour". Pourtant, la première forme rend sans doute la condition de la structure du code plus explicite. Existe-il des raisons de préférer l'un sur l'autre?

(Connexe: si une fonction ont une seule instruction de retour?)

Answer 1

Dans ce cas, les else seraient redondants et créeraient une indentation supplémentaire inutile pour le code principal de la fonction.

Answer 2

Dans mon expérience, cela dépend du code. Si je suis "gardiennage" à l'encontre de quelque chose, je vais le faire:

if (inputVar.isBad()) {
    return;
}

doThings();

Le point est clair: Si l'énoncé est faux, je ne veux pas la fonction pour continuer.

D'autre part, il y a quelques fonctions avec plusieurs options, et dans ce cas je voudrais écrire comme ceci:

if (inputVar == thingOne) {
    doFirstThing();
} else if (inputVar == secondThing) {
    doSecondThing();
} else {
    doThirdThing();
}

Même si elle peut être écrite comme:

if (inputVar == thingOne) {
    doFirstThing();
    return;
}
if (inputVar == thingTwo) {
    doSecondThing();
    return;
}
doThingThree();
return;

Il s'agit vraiment de quelle manière la plupart des montre clairement ce que fait le code (pas nécessairement bits de code est plus court ou le moins de traces).

Answer 3

Ceci est un modèle appelé Guard Clause . L'idée est de procéder à toutes les vérifications initiales afin de réduire les conditions imbriquées afin d'améliorer la lisibilité.

Du lien:

 double getPayAmount() {
    double result;
    if (_isDead) {
        result = deadAmount();
    } else {
        if (_isSeparated) {
            result = separatedAmount();
        } else {
            if (_isRetired) {
                result = retiredAmount();
            } else {
                result = normalPayAmount();
            }
        }
    }

    return result;
}


double getPayAmount() {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();

    return normalPayAmount();
};
 

Answer 4

Vous verrez tout ceci:

if (condition) {
    return var;
}
// by nature, when execution reaches this point, condition can only be false,
// therefore, the else is unnecessary
return other_var;

La plupart du temps l'ajout d'une clause else est non seulement inutile, dans ce cas, mais beaucoup de fois, il obtient optimisé à l'écart par le compilateur.

Pensez à la façon dont l'ordinateur pense de ce code (en termes de code machine, simplifié en pseudocode ici pour les besoins de la démonstration):

0x00: test [condition]
0x01: if result of test was not true, goto [0x04]
0x02: push [var] onto stack
0x03: goto [0x05]
0x04: push [other_var] onto stack
0x05: return from subroutine

Le code (encore une fois, c'est un pseudo et non pas de l'assemblée), agissent de la même façon pour un if/then/else conditionnelle.

Il est, par beaucoup de personnes, considérées comme des mauvaises et/ou de confusion pratique d'avoir plusieurs points de sortie d'une fonction, en tant que programmeur doit penser de tout le chemin par le biais de son code. Une autre pratique est la suivante:

return (condition) ? var : other_var;

Cela permet de simplifier le code, et ne crée pas de nouveaux points de sortie.

Answer 5

Je préfère l'écrire comme ça:

 boolean containsSmiley(String s) {
    return s != null && s.contains(":)");
}