关于使用块返回的最佳实践

哪种方式更好的做法：从using语句中的方法返回一个值或者之前声明一个变量，将其设置在内部并在之后返回？

 public int Foo() { using(..) { return bar; } }

要么

 public int Foo() { var b = null; using(..) { b = bar; } return b; }

我更喜欢第一个例子。更少的变量，更少的代码行，更容易理解，更易于维护……

 public int Foo() { using(..) { return bar; } }

遵循“少即是多”的原则（实际上只是KISS的一个变种），前者。维护的代码行数较少，语义没有变化，可读性也不会下降（可以说这种风格更易于阅读）。

从使用Statement – MSDN

using语句确保即使在对象上调用方法时发生exception，也会调用Dispose。您可以通过将对象放在try块中然后在finally块中调用Dispose来实现相同的结果; 实际上，这就是编译器如何翻译using语句。

来自try-finally（C＃参考）

最后用于保证语句代码块的执行， 而不管前面的try块是如何退出的。

要回答你的问题，是的，可以从using语句返回。

第二个显然更好，你可以通过编写测试程序来validation它是否正常工作。

using语句本身不能有值，这是一个限制。假设您有一个名为Open的方法，它返回一个打开的FileStream ，并且您想要获取文件的长度：

 Console.WriteLine(Open().Length);

那里的错误是你没有处理FileStream 。所以你必须写（类似于你的例子）：

 long length; using (FileStream file = Open()) length = file.Length; Console.WriteLine(length);

但是使用简单的扩展方法，您可以改为：

 Console.WriteLine(Open().Use(file => file.Length));

很好，整洁， FileStream得到妥善处理。

没有理由不这样，因为using语句转换为try...finally块，并且finally部分保证被执行（即使通过返回或未处理的exception）。

这真的取决于个人喜好。你会在这个特定的围栏的两边找到论据。我自己，我赞成选项1：尽快回来。我相信它更好地表达了代码的意图; 没有理由比你必须坚持更长时间。如果您已完成所有工作，请返回。

有时，您将拥有多个可能的返回点，并且“方法结束”工作（日志记录，清理）可能会导致您返回单个return语句。没有什么可怕的，但你可以经常处理finally块中的那些情况或面向方面编程中的方面。

我觉得第二个更好

 public int Foo() { using(..) { return bar; } }

在使用这种方式时出现的一件事是我们在使用之间返回，所以对象（我们已经包装使用）将被处理掉，答案是肯定的，因为A using语句只是try /的混合最后阻止，也可以从try块返回。返回表达式将被评估，然后finally块将被执行，然后该方法将返回。所以前进:)