Une fonction devrait-elle avoir une seule déclaration de retour?

Question

Y a-t-il de bonnes raisons pour lesquelles il est préférable d'avoir une seule déclaration de retour dans une fonction?

Ou est-ce correct de revenir d'une fonction dès qu'il est logique de le faire, ce qui signifie qu'il peut y avoir plusieurs instructions de retour dans la fonction?

Answer 1

J’ai souvent plusieurs déclarations au début d’une méthode pour retourner des situations « faciles ». Par exemple, ceci :

... on peut faire plus lisible (AMHA) comme ceci :

Alors oui, je pense que c’est bien d’avoir plusieurs « points de sortie » d’une fonction/méthode.

Answer 2

Personne n'a mentionné ou cité de Code Complet donc je vais le faire.

17.1 retour

Réduire le nombre de retours dans chaque routine. Il est plus difficile de comprendre une routine si, en le lisant, au fond, vous êtes pas au courant de la possibilité qu'il est revenu quelque part au-dessus.

Utilisez un retour quand il améliore la lisibilité. Dans certaines routines, une fois que vous connaissez la réponse, vous voulez le retourner à l'appel de la routine immédiatement. Si la routine est définie de telle sorte qu'il ne nécessite pas de nettoyage, pas de retour immédiat signifie que vous devez écrire plus de code.

Answer 3

Je dirais qu'il serait très imprudent de décider arbitrairement à l'encontre de plusieurs points de sortie que j'ai trouvé la technique pour être utile dans la pratique , encore et encore, en fait, j'ai souvent refait code existant à de multiples points de sortie pour plus de clarté. Nous pouvons comparer les deux approches ainsi:-

string fooBar(string s, int? i) {
  string ret = "";
  if(!string.IsNullOrEmpty(s) && i != null) {
    var res = someFunction(s, i);

    bool passed = true;
    foreach(var r in res) {
      if(!r.Passed) {
        passed = false;
        break;
      }
    }

    if(passed) {
      // Rest of code...
    }
  }

  return ret;
}

Comparez cela à l'endroit du code où de multiples points de sortie sont autorisés:-

string fooBar(string s, int? i) {
  var ret = "";
  if(string.IsNullOrEmpty(s) || i == null) return null;

  var res = someFunction(s, i);

  foreach(var r in res) {
      if(!r.Passed) return null;
  }

  // Rest of code...

  return ret;
}

Je pense que la dernière est beaucoup plus clair. Aussi loin que je peux dire à la critique de plusieurs points de sortie est plutôt archaïque du point de vue de ces jours.

Answer 4

Actuellement, je suis en train de travailler sur une base de code où deux personnes travaillant sur aveuglément abonnez-vous à la "seul point de sortie" de la théorie et je peux vous dire qu'à partir de l'expérience, c'est une horrible horrible pratique. Il rend le code extrêmement difficile à gérer et je vais vous montrer pourquoi.

Avec le "single point de sortie" de la théorie, vous inévitablement se retrouver avec du code qui ressemble à ceci:

function()
{
    HRESULT error = S_OK;

    if(SUCCEEDED(Operation1()))
    {
        if(SUCCEEDED(Operation2()))
        {
            if(SUCCEEDED(Operation3()))
            {
                if(SUCCEEDED(Operation4()))
                {
                }
                else
                {
                    error = OPERATION4FAILED;
                }
            }
            else
            {
                error = OPERATION3FAILED;
            }
        }
        else
        {
            error = OPERATION2FAILED;
        }
    }
    else
    {
        error = OPERATION1FAILED;
    }

    return error;
}

Non seulement cela contribue à rendre le code très difficile à suivre, mais maintenant dire plus tard vous avez besoin de revenir en arrière et ajouter une opération entre 1 et 2. Vous devez tiret à peu près tout le flipper fonction, et bonne chance à vous assurer que tous les if/else conditions et les croisillons sont appariés correctement.

Cette méthode rend le code d'entretien extrêmement difficile et sujette aux erreurs.

Answer 5

La programmation structurée dit que vous ne devriez jamais avoir une instruction return par fonction. C'est à la limite de la complexité. Beaucoup de gens comme Martin Fowler soutiennent qu'il est plus simple d'écrire des fonctions avec plusieurs instructions return. Il présente cet argument dans le classique refactoring livre qu'il a écrit. Cela fonctionne bien si vous suivez d'autres de ses conseils et de l'écrire de petites fonctions. Je suis d'accord avec ce point de vue, et seul le strict programmation structurée puristes adhérer à la déclaration unique des déclarations par fonction.