Est-ce une mauvaise pratique d'utiliser return dans une méthode void ?

Question

Imaginez le code suivant :

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

Est-il possible d'utiliser un return dans une méthode void ? Cela a-t-il un impact sur les performances ? Ou bien il serait préférable d'écrire un code comme celui-ci :

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

Answer 1

Il existe une autre bonne raison d'utiliser des gardes (par opposition au code imbriqué) : Si un autre programmeur ajoute du code à votre fonction, il travaille dans un environnement plus sûr.

Pensez-y :

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

contre :

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

Maintenant, imaginez qu'un autre programmeur ajoute la ligne : obj.DoSomethingElse() ;

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

Bien sûr, il s'agit d'un cas simpliste, mais le programmeur a ajouté un crash au programme dans la première instance (code imbriqué). Dans le deuxième exemple (sortie anticipée avec gardes), une fois que vous avez passé la garde, votre code est protégé contre l'utilisation involontaire d'une référence nulle.

Bien sûr, un grand programmeur ne fait pas (souvent) de telles erreurs. Mais il vaut mieux prévenir que guérir - nous pouvons écrire le code de manière à éliminer complètement cette source potentielle d'erreurs. L'imbrication ajoute de la complexité. Les meilleures pratiques recommandent donc de remanier le code pour réduire l'imbrication.

Answer 2

Mauvaise pratique ? ?? Pas du tout. En fait, il est toujours préférable de gérer les validations en retournant de la méthode au plus tôt si les validations échouent. Sinon, il en résulterait une quantité énorme de ifs et elses imbriqués. Une terminaison précoce améliore la lisibilité du code.

Vérifiez également les réponses à une question similaire : Devrais-je utiliser l'instruction return/continue au lieu de if-else ?

Answer 3

Ce n'est pas une mauvaise pratique (pour toutes les raisons déjà évoquées). Cependant, plus vous avez de retours dans une méthode, plus il est probable qu'elle doive être divisée en méthodes logiques plus petites.

Answer 4

Le premier exemple consiste à utiliser une instruction de garde. Extrait de Wikipedia :

En programmation informatique, un garde est un expression booléenne qui doit être évaluée à vrai si l'exécution du programme doit continuer dans la branche en question.

Je pense qu'avoir un tas de gardes en haut d'une méthode est une façon parfaitement compréhensible de programmer. Cela revient à dire "n'exécutez pas cette méthode si l'une de ces conditions est vraie".

Donc, en général, c'est comme ça :

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

Je pense que c'est beaucoup plus lisible alors :

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

Answer 5

Il n'y a pas de pénalité de performance, mais le second morceau de code est plus lisible et donc plus facile à maintenir.