通过返回与If / Else控制流程

哪一个更好（通过if 返回或控制流的隐式控制流） – 见下文。请解释一下你认为哪个是优点/缺点。我喜欢选项A，因为它的代码更少。

流程返回：

public ActionResult Edit(MyClass class) { if (!class.Editable) return null; class.Update(); return View(); }

 public ActionResult Edit(MyClass class) { if (class.Editable) { class.Update(); return View(); } else { return null; } }

这个具体的例子没什么区别，但总的来说我喜欢第一种方法，因为它使用了一个保护子句来提前返回。如果您开始向第二种方法添加嵌套条件，您将看到您的代码可读性会受到影响。 Guard子句可以大大减少嵌套深度，并且真正增强了代码的可读性。

我个人喜欢if/else方法。首先，你的if语句是正面的，而不是负面的，使其更容易阅读。对于两个，你已经用大括号括起条件，我是那种风格的粉丝。

无论如何，跟随第二个比第一个更容易。这总是在我的书中获胜。

为了可读性和可维护性，我更喜欢第二种方法。可读性因为它比第一种方法对我来说更“清洁”，并且可维护性，因为如果我需要修改if或else子句，我不必担心添加花括号。此外，如果不包括新行，第一种方法只比第二种方法少7个字符，这几乎不是选择第一种方法的理由。

那就是说，我其实更喜欢这个：

 public ActionResult Edit(MyClass class) { ActionResult rv = null; if (class.Editable) { class.Update(); rv = View(); } return rv; }

这是更多的代码，但我现在可以在return语句上设置一个断点来检查返回的值，而不是必须设置两个断点来在你提供的两个选项中执行相同的操作。

这两个语句都通过if语句控制流。这只是你如何处理这个条件的问题。

在编写像这样的逻辑语句时，我总是处于困境之中。我的一部分喜欢第一个选项，因为它的代码少了一点。我的另一部分喜欢第二种选择，因为它更容易遵循逻辑流程。使用第一个选项时，很容易错过返回语句，这可能导致将来出现可管理性问题。

……出于这个原因，第二个选项总是赢得我的书。编写比尝试快捷方式更容易阅读和维护的代码更好。

我更喜欢我认为是执行少量代码的那个。
如果它更常见于class.Editable是假的那么我会去A.

但是这个例子在任何一种情况下都没有太大的优势。

在任何给定情况下，开发人员应分析输入并调整代码以在最常见的输入数据上进行优化。

编辑：
澄清：
通过执行更少的代码我实际意味着最有效…

在这种情况下，我会使用选项A.在这种情况下，您正在进行输入validation，然后在输入无效（不可编辑）时阻止执行其余代码。这使得函数的整个主体不受大if / else语句的影响，并使其更具可读性。

但是，我也会考虑提出exception而不是重新调整null – 假设将不可编辑的对象传入“编辑”函数并不是正常现象。

它们都是有效的选择，一个不一定比另一个好。你选择哪一个最终是个人偏好。是的，选项A导致的代码略少，但总体来说它们几乎相同。

在这两种情况下，您都通过if和return来控制流量。这真的是一个你更喜欢看布尔逻辑的问题 – 消极还是积极？

ActionResult是枚举还是基类？如果它是枚举，为什么在Edit返回看似枚举的内容时返回null ？简单地返回一个ActionResult值，表明由于对象不处于可编辑状态而没有采取任何操作，这不是更清晰吗？

提前退出 – 我更愿意看到导致该方法退出的所有条件，而不需要预先做很多事情。如果我可以完全避免它，我会避免其他陈述。

这实际上是Code Contracts人群中一个相当突出的思想流派。

使用return的第一个选项更好，因为：

这种方法的一个支持者（回归）是Marcus Zarra ，在Cocoa中是我的女朋友编码风格

我更喜欢第一个选项，前提是您检查的情况是方法调用有效时需要满足的保护/前提条件。虽然您可以争辩是否应该返回null，或者抛出（Argument）exception。当一个类不可编辑时，它真的应该是这个方法的参数吗？

也许更好的选择是创建一个IEditable接口，并在你正在传递一个实例的类上实现它。

我更喜欢if/else 。对我来说，易读性，可读性和可维护性是最重要的。

我也更喜欢选项1.对我而言，它更像是一本书。此外，我总是对选项2结尾处没有回归感到痛心。