Quelle est la meilleure pratique: renvoyez une valeur d'une méthode à l'intérieur d'un à l'aide de code> instruction ou déclarez une variable avant, définissez-la à l'intérieur et retournez-la après? public int Foo()
{
var b = null;
using(..)
{
b = bar;
}
return b;
}
7 Réponses :
aucune raison de ne pas car ce à l'aide de instruction se traduit par un Essayez ... Enfin Bloc et la partie enfin est garantie pour être exécuté (même à travers un retour ou une exception non gérée).
Quelqu'un doit toujours signaler cela - le bloc enfin est pas "garanti" à exécuter du tout. Il existe des circonstances bien définies dans lesquelles il s'exécutera, et d'autres où il ne le fera pas.
Avoir des exemples où il ne va pas?
@Earwicker: Si les cas où il ne sera pas exécuté de 0,01%, alors je pense à la plupart des fins, nous pouvons dire que c'est "garanti".
En regardant la citation de Stan R de la référence C #, il semblerait que vous n'ayez pas mal à ce sujet.
Il est garanti d'exécuter dans le même sens que tout autre code est garanti.
@Joel Coelhoorn - qui est à dire, il n'est pas garanti de courir.
@ J0RD4N - Beaucoup de gens trouvent cette page une référence pratique: thedailywtf.com/articles/my-tales. ASPX
Non pas que je suis d'accord avec la conclusion de celui-ci - enfin Les blocs sont un meilleur endroit pour mettre un code de transaction important de manière critique que n'importe où ailleurs. Il est tout simplement très important de savoir comment les empêcher de courir quand il est préférable qu'ils ne fonctionnent pas (par exemple, un état de programme non valide inattendu).
@Arwicker: Je pourrais toujours désactiver l'ordinateur, auquel cas, il ne sera pas exécuté.
@Arwicker: Je parie que 99,9% de tous les développeurs .NET pourraient aller toute leur carrière sans avoir à réfléchir à la façon d'arrêter enfin de l'exécution de l'exécution. Cela ajoute seulement de la confusion pour apporter de tels cas de bord dans une discussion comme celle-ci.
@John Saunders - Je pense que nous pouvons tous tirer profiter de ce que lorsque notre programme ne se passe pas continuer à essayer d'essayer de "nettoyer" et (par exemple), supprimez un groupe de fichiers temporaires et de supprimer potentiellement les mauvaises, ou Détruire la preuve que nous devons identifier le problème ou jeter plus d'exceptions (obscurcissant l'original).
Je préfère le premier exemple. Moins de variables, moins de lignes de code, plus faciles à suivre, plus faciles à maintenir ...
Cela revient vraiment à la préférence personnelle. Vous trouverez des arguments des deux côtés de cette clôture particulière. Moi-même, je préfère l'option 1: retourner dès que vous le pouvez. Je crois que cela exprime mieux l'intention du code; Il n'y a aucune raison de rester plus longtemps que vous ne l'avez. Si vous avez terminé tout votre travail, retournez.
Parfois, vous aurez plusieurs points de retour possibles et "Fin de méthode" Travail (enregistrement, nettoyage) qui pourrait vous amener à une déclaration de retour unique. Rien de terrible à ce sujet, mais vous pouvez souvent gérer ces situations dans enfin blocs ou avec des aspects dans la programmation orientée forme.
Je suis d'accord sur la préférence personnelle. Je préfère revenir en bas / fin de la méthode. Les directives de codage dictent souvent cela aussi. Cela vient probablement également du fait que les méthodes sont parfois trop longues, ce qui entraîne des méthodes illisibles. Gardez-les vraiment courts et vos méthodes sont à nouveau lisibles. C'est donc l'une de ces réponses "Cela dépend" que je suppose! ;) Les regards des meilleures pratiques, AFAIK n'est vraiment pas un, c'est plus une question de préférence.
Suivre le principe "moins est plus" (vraiment une variante de Kiss ), l'ancien. Il y a moins de lignes de code à maintenir, sans changement de sémantique et aucune perte de lisibilité (sans doute, ce style est plus facile à lire).
de Utilisation de l'instruction - MSDN
L'utilisation de l'utilisation garantit que Disposer est appelé même si une exception se produit pendant que vous appelez des méthodes sur l'objet. Vous pouvez atteindre le même résultat en mettant l'objet à l'intérieur d'un bloc d'essai puis appelant éliminer dans un blocage enfin; En réalité, C'est ainsi que l'utilisation de l'utilisation est Traduit par le compilateur.
du Essayez-enfin (référence C #)
finalement est utilisé pour garantir un Le bloc de déclaration du code exécute Quel que soit la manière dont le bloc d'essai précédent est sorti.
Pour répondre à votre question, oui, c'est bien de revenir d'une déclaration en utilisant.
Il a demandé lequel de ce qui précède est une meilleure pratique, pas pour la sémantique de l'utilisation de l'utilisation. On peut soutenir que la sémantique est pertinente ici, mais cela ne répond pas à la question posée.
@Jason: assez juste..Le titre de la question est "Est-il correct de revenir d'une méthode à l'aide d'une déclaration utilisée?" .. vous pouvez voir que je ne suis pas le seul à lire la question de cette façon.
@Stan R: Je vois le potentiel de confusion, mais le post pose clairement des questions sur les meilleures pratiques, pas si le bloc enfin exécutera ou non (c'est-à-dire sémantique).
La seconde est clairement meilleure et vous pouvez vérifier que cela fonctionne bien en écrivant un programme de test.
Le Le bug Il est que vous n'êtes pas disposé au mais avec un Méthode d'extension simple , vous pouvez écrire cela à la place: P> à l'aide de code> L'instruction elle-même ne peut avoir une valeur, qui est une limitation. Supposons que vous ayez une méthode appelée ouverte code> qui renvoie un open (code> filtream code> et vous souhaitez obtenir la longueur du fichier: p> filtream code>. Donc, vous devez écrire (semblable à votre exemple): p> Console.WriteLine(Open().Use(file => file.Length));
Soigné, mais illisible en même temps :-)
heh c'est assez soigné. Thx pour une idée intelligente.
@Scott P - C'est essentiellement la même idée que le ? : opérateur (une "expression" équivalent à si ). Certains trouvent ? : moins lisible que l'équivalent si instruction, je trouve que cela peut être parfois plus clair. L'élimination des noms de variables contribue souvent à la clarté.
Je me sens deuxième mieux une chose qui se pose à l'esprit lors de l'utilisation de cette façon, c'est que nous retournons entre l'utilisation de l'utilisation de sorte que l'objet (que nous avons enveloppé d'utilisation) sera disposé, la réponse est oui
Étant donné qu'une déclaration utilisée ne fait que le mélange d'essayer / enfin, il convient de revenir d'un bloc d'essai. L'expression de retour sera évaluée, puis le bloc enfin sera exécuté et que la méthode reviendra alors. :)