通过返回与if/else[关闭]的控制流

在这个特定的例子中没有太大的区别,但是一般来说,我喜欢第一种方法,因为它使用 guard clause 早点回来。如果您开始向第二种方法添加嵌套条件,您将看到您的代码可读性将受到影响。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 语句。这只是你如何处理这种情况的问题。

当涉及到写这样的逻辑语句时,我总是犹豫不决。我有一部分喜欢第一个选项,因为它的代码少了一点。我的另一部分喜欢第二种选择,因为遵循逻辑流程要容易得多。使用第一个选项,很容易错过返回语句,这可能导致未来的可管理性问题。

…正因为如此,我书中的第二个选择总是赢的。写一些更容易阅读和维护的代码比尝试走捷径要好。

我更喜欢我认为执行代码较少的那个。
如果这是更常见的类。编辑为假,那么我会去。

但在这两种情况下,这个例子都没有提供太多的优势。

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

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

在这种情况下,我将使用选项A。在这种情况下,您将进行输入验证,然后在输入无效(不可编辑)时阻止执行其余代码。这使函数的整个主体远离一个大型if/else语句,并使其更具可读性。

但是,我也会考虑引发异常,而不是重新调整空值——也就是说,假设将不可编辑的对象传递到“edit”函数中不是正常的情况。

它们都是有效的选择,其中一个并不一定比另一个更好。最终,你选择的是个人偏好。是,选项A导致 轻微地 代码更少,但总的来说它们几乎相等。

在这两种情况下,都是通过if和return控制流。这真的是一个问题,你更喜欢看到你的布尔逻辑-负或正?

是 ActionResult 枚举还是基类?如果是枚举,为什么要返回 null 什么时候 Edit 返回似乎是枚举的内容?把一个 行动结果 指示由于对象不处于可编辑状态而未执行任何操作的值?

尽早退出-我更喜欢看到所有的条件,这将导致方法退出而不做太多的前期工作。如果我能避免的话,我就避免其他的说法。

这实际上是法典契约群体中一个相当突出的思想流派。

第一种选择是使用RETURN,因为:

1. 你有一个地方可以放置所有的保护和前提条件,靠近你的断言和所有的东西。
2. 对我来说,更容易想到“让我们看看所有可能的错误,然后再回来。”从这一点上来说,我拥有我所需要的一切 Happy Path
3. 如果确实使用if/else方法,则该方法/函数中的所有代码都缩进了。加上其他的,如果,或为,事情开始变得有趣。

这种方法(返回)的一个支持者是 Marcus Zarra ,在 Cocoa is my Girlfriend coding style

我更喜欢第一个选项,前提是您检查的情况是需要满足保护/前提条件才能使方法调用有效。尽管您可以争论是否应该返回空值,或者抛出(参数)异常。当一个类不可编辑时,它真的应该是这个方法的参数吗?

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

我更喜欢 if/else 也一样。易读性、可读性和可维护性在我看来是最重要的。

我也喜欢选项1。对我来说,它读起来更像一本书。而且,我总是为在选项2的末尾没有返回而感到痛苦。