Inverser l'instruction "if" pour réduire l'imbrication

Question

Quand j'ai lancé ReSharper sur mon code, par exemple:

     if (some condition)
    {
        Some code...            
    }
 

ReSharper m'a donné l'avertissement ci-dessus (Inverser "si" déclaration pour réduire l'imbrication), et a suggéré la correction suivante:

    if (!some condition) return;
   Some code...
 

Je voudrais comprendre pourquoi c'est mieux. J'ai toujours pensé qu'en utilisant "return" au milieu d'une méthode problématique, un peu comme "goto".

Answer 1

Un retour dans le milieu de la méthode n'est pas nécessairement mauvais. Il pourrait être mieux de retourner immédiatement il fait l'intention de le code plus clair. Par exemple:

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

Dans ce cas, si _isDead est vrai, on peut tout de suite sortir de la méthode. Il vaudrait peut-être mieux la structure de cette façon au lieu de cela:

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

J'ai choisi ce code à partir du refactoring catalogue. Ce refactoring est appelé: Remplacer Conditionnels Imbriqués avec le Gardien de Clauses.

Answer 2

C'est un peu un argument religieux, mais je suis d'accord avec ReSharper que vous préférez moins de nidification. Je crois que cela l'emporte sur le négatif, d'avoir de multiples voies du retour d'une fonction.

La clé raison pour avoir moins de nidification est d'améliorer la lisibilité du code et de la maintenabilité. Rappelez-vous que de nombreux autres développeurs auront besoin de lire votre code dans l'avenir, et le code avec moins d'indentation est généralement beaucoup plus facile à lire.

Les conditions préalables sont un excellent exemple de l'endroit où il est bon de revenir plus tôt au début de la fonction. Pourquoi la lisibilité du reste de la fonction d'être affectées par la présence d'une condition de vérifier?

Comme pour les négatifs au sujet de revenir plusieurs fois à partir d'une méthode - débogueurs sont assez puissant maintenant, et il est très facile de savoir exactement où et quand une fonction particulière est de retour.

Le fait d'avoir plusieurs retours dans une fonction, on ne va pas affecter l'entretien du programmeur de l'emploi.

Mauvaise lisibilité du code de la volonté.

Answer 3

L'idée de ne revenir à la fin d'une fonction revint de jours avant de langues, avec le soutien des exceptions. Il a permis à des programmes de compter sur d'être capable de mettre de code de nettoyage à la fin d'une méthode, et puis en étant sûr qu'il pourrait être appelé et quelques autres programmeur de ne pas cacher un retour à la méthode qui a causé le code de nettoyage pour être ignorée. Sauté de nettoyage de code pourrait entraîner un mémoire ou une perte de ressources.

Cependant, dans un langage qui prend en charge les exceptions, il ne prévoit pas de telles garanties. Dans un langage qui prend en charge les exceptions, l'exécution de toute instruction ou de l'expression peut provoquer un flux de contrôle qui provoque la méthode à la fin. Cela signifie que le nettoyage doit se faire à travers l'utilisation de la enfin ou à l'aide de mots-clés.

De toute façon, je le dis, je pense que beaucoup de gens citer " le seul retour à la fin d'une méthode directive, sans comprendre pourquoi il n'a jamais été une bonne chose à faire, et que la réduction de nidification pour améliorer la lisibilité est probablement un meilleur objectif.

Answer 4

C'est bien sûr subjectif, mais je pense qu'il améliore fortement sur deux points:

• Il est maintenant évident que votre fonction n'a plus rien à faire si condition est valide.
• Il maintient le niveau d'imbrication bas. La nidification nuit à la lisibilité plus que vous ne le pensez.

Answer 5

Plusieurs points de retour étaient un problème dans C (et dans une moindre mesure C ++) car ils vous obligeaient à dupliquer le code de nettoyage avant chacun des points de retour. Avec le garbage collection, le try | finally construct et using blocks, il n'y a vraiment aucune raison pour que vous ayez peur d'eux.

En fin de compte, cela revient à ce que vous et vos collègues trouvez plus facile à lire.