Quelle syntaxe est la meilleure pour la valeur de retour?

Question

J'ai procédé à une révision de code en masse et l'un des motifs que j'ai remarqués est le suivant:

public bool MethodName()
{
    bool returnValue = false;
    if (expression)
    {
        // do something
        returnValue = MethodCall();
    }
    else
    {
        // do something else
        returnValue = Expression;
    }

    return returnValue;
}

Ce n’est pas comme cela que j’aurais fait cela; j’aurais simplement retourné la valeur quand j’aurais su ce que c’était. lequel de ces deux modèles est le plus correct?

J'insiste sur le fait que la logique semble toujours être structurée de telle sorte que la valeur de retour est affectée dans un seul plave et qu'aucun code ne soit exécuté après son affectation.

Answer 1

Il existe une longue discussion sur ce sujet ici . .

Answer 2

Beaucoup de gens recommandent d'avoir un seul point de sortie de vos méthodes. Le modèle que vous décrivez ci-dessus suit cette recommandation.

L’essentiel de cette recommandation est que, si vous devez nettoyer de la mémoire ou un état avant de revenir à la méthode, il est préférable d’avoir ce code à un seul endroit. le fait d'avoir plusieurs points de sortie entraîne la duplication du code de nettoyage ou des problèmes potentiels dus à l'absence de code de nettoyage à un ou plusieurs des points de sortie.

Bien sûr, si votre méthode comporte deux lignes ou si elle n’a pas besoin d’être nettoyée, vous pourriez avoir plusieurs retours.

Answer 3

J'aurais utilisé ternaire pour réduire les structures de contrôle ...

return expression ? MethodCall() : Expression;

Answer 4

Je pense que je serai dans la minorité, mais j'aime bien le style présenté dans l'exemple. Il est facile d'ajouter une instruction de journal et de définir un point d'arrêt, IMO. De plus, lorsqu'il est utilisé de manière cohérente, il semble plus facile de & "; Correspondance de motif &"; que d'avoir plusieurs retours.

Je ne suis pas sûr qu'il existe un & "correct &"; répondez à cela, cependant.

Answer 5

Certains instituts d'apprentissage et livres préconisent la pratique du retour unique.

Que ce soit meilleur ou non, c'est subjectif.

Answer 6

Cela ressemble à une mauvaise conception POO. Peut-être faudrait-il la refactoriser à un niveau supérieur à celui d'une méthode unique.

Sinon, je préfère utiliser un opérateur ternaire, comme ceci:

return expression ? MethodCall() : Expression;

Il est plus court et plus lisible.

Answer 7

Renvoyez immédiatement une méthode dans l’une des situations suivantes:

1. Vous avez trouvé une condition limite et devez renvoyer une valeur unique ou sentinelle: if (node.next = null) return NO_VALUE_FOUND;
2. Une valeur / un état requis est false, le reste de la méthode ne s'applique donc pas (c'est-à-dire une clause de garde). Exemple: if (listeners == null) return null;
3. La méthode a pour but de rechercher et de renvoyer une valeur spécifique, par exemple: if (nodes[i].value == searchValue) return i;
4. Vous êtes dans une clause qui renvoie une valeur unique de la méthode non utilisée ailleurs dans la méthode: if (userNameFromDb.equals(SUPER_USER)) return getSuperUserAccount();

Sinon, il est utile de n'avoir qu'une seule instruction return afin de faciliter l'ajout de la journalisation du débogage, du nettoyage des ressources et du suivi de la logique. J'essaie d'abord de traiter les 4 cas ci-dessus, s'ils s'appliquent, puis de déclarer une variable nommée result(s) aussi tard que possible et d'attribuer des valeurs à celle-ci au besoin.

Answer 8

Ils accomplissent tous les deux la même tâche. Certains disent qu'une méthode ne devrait avoir qu'une entrée et un point de sortie.

Answer 9

Je l'utilise aussi. L'idée est que les ressources peuvent être libérées dans le flux normal du programme. Si vous sortez d'une méthode à 20 endroits différents et que vous devez appeler cleanUp () avant, vous devrez ajouter une autre méthode de nettoyage 20 fois (ou tout refactoriser)

Answer 10

Je suppose que le codeur a choisi de définir un objet toReturn en haut de la méthode (par exemple, List < Foo > toReturn = new ArrayList < Foo gt; ();) puis le peupler lors de l'appel de la méthode et a décidé de l'appliquer à un type de retour booléen, ce qui est impair.

Peut également être un effet secondaire d'une norme de codage indiquant que vous ne pouvez pas retourner au milieu d'un corps de méthode, mais uniquement à la fin.

Answer 11

Même si aucun code n'est exécuté après l'attribution de la valeur de retour, cela ne signifie pas qu'il ne sera pas nécessaire d'ajouter du code ultérieurement.

Ce n’est pas le plus petit élément de code qui pourrait être utilisé, mais il est très convivial pour le refactoring.

Answer 12

Delphi force ce modèle en créant automatiquement une variable appelée " Résultat " qui sera du type de retour de la fonction. Quel que soit & Quot; Résultat & Quot; est quand la fonction se termine, est votre valeur de retour. Donc, il n'y a pas de & Quot; return & Quot; mot-clé du tout.

function MethodName : boolean;
begin
  Result := False;
  if Expression then begin
    //do something
    Result := MethodCall;
  end
  else begin
    //do something else
    Result := Expression;
  end;

  //possibly more code
end;

Answer 13

Le modèle utilisé est détaillé - mais il est également plus facile de déboguer si vous voulez connaître la valeur de retour sans ouvrir la fenêtre Registres et vérifier EAX.