web-dev-qa-db-fra.com

Sortir d'une méthode nulle?

J'ai cette méthode (code modifié):

public static void PublishXmlForCustomTypes(MyOwnClass DefaultOutputInformation)
{
    if (DefaultOutputInformation != null)
    {
        ///lot of code
    }
}

et tout mon code était à l'intérieur de l'instruction if et après y avoir réfléchi, je suis passé à ceci:

public static void PublishXmlForCustomTypes(MyOwnClass DefaultOutputInformation)
{
    if (DefaultOutputInformation == null)
    {
        return;
    }
    ///lot of code
}

Pour autant que je l'ai testé, il semble être strictement équivalent mais est-ce vraiment le cas? Je veux dire, la déclaration de "retour" nous sort de la méthode, n'est-ce pas?

c#coding-style
28
user1153455

C'est strictement équivalent et la deuxième version est la voie à suivre :)

42
Guillaume Slashy

Oui, c'est très bien.

Certaines personnes s'en tiennent dogmatiquement à "un point de sortie par méthode" - ce qui était approprié quand il était relativement difficile de s'assurer que vous faisiez toujours la bonne quantité de nettoyage à la fin d'une fonction en C, par exemple ... mais c'est pas vraiment nécessaire en C #.

Personnellement, je pense qu'il est approprié de revenir dès que vous savez que vous avez fait tout le travail que vous voulez vraiment dans une méthode. Utilisation try/finally ou using pour effectuer un travail supplémentaire de "nettoyage mais je quitte".

7
Jon Skeet

oui return vous sort de la méthode; si vous avez un bloc finally et que vous appelez return depuis le bloc try, le bloc finally est quand même exécuté.

4
Davide Piras

Oui, l'instruction return termine la méthode.

3
Jorge

Oui, le retour vous sortira du code. Il s'agit généralement d'une bonne pratique en tant que toute première étape d'une fonction de vérifier que les paramètres transmis correspondent à ce que vous pensez qu'ils sont et de sortir (via le retour ou la levée d'une exception) afin de ne pas effectuer de traitement inutile uniquement pour doivent abandonner plus tard dans la fonction.

2
FuriousGeorge

En regardant le code révisé, le second est la voie à suivre. Tout en étant fonctionnellement équivalent, pensez au cas où vous avez passé 4 variables différentes à une fonction que vous souhaitez vérifier. Au lieu d'avoir une instruction do a nasty 4 level if avec {partout, la deuxième méthode vous permet de nettoyer l'apparence du code et de ne pas ajouter de niveaux de crochets inutiles. Si vous écrivez en C/C++, vous pouvez même en faire une macro telle que VERYIFY_NOT_NULL (x) et rendre le code Nice et soigné.

Le code lisible/maintenable l'emporte sur les nano-secondes de performances 99% du temps.

1
FuriousGeorge

Oui, vos hypothèses sont correctes.

Pour quelques informations, découvrez dualité .

1
leppie

Oui, c'est exactement la même chose, vous pouvez lire la documentation MSDN sur le mot clé return pour bien comprendre comment cela fonctionne: http://msdn.Microsoft.com/en-us/library/1h3swy84.aspx =

Quant à décider quelle voie est la meilleure: les deux sont bonnes, mais la deuxième version la rend plus lisible car alors tout votre code n'est pas dans un bloc if. De cette façon, vous pouvez voir ce que la condition fait vraiment facilement au lieu de lire tout le code de la méthode.

1
StevenGilligan

En effet, le return vous sort de la méthode, il est donc équivalent à la première façon que vous avez utilisée. Le meilleur moyen dépend de votre code, bien que je préfère généralement la deuxième version.

1
Grizzly