0

我指的是以下内容：

void setup_gui()
{
    if (some_condition)
        some_button.disable();

    ...
}

void some_button_click()
{
    // Is this a good practice?
    if (some_condition)
        return;

   ...
}

添加该检查可确保程序不会运行该操作，但它也可以被视为隐藏错误（some_button_click() 必须根本没有运行）。

那么，你怎么看呢？这是一种安全的编码实践还是隐藏了一个错误？

4

4 回答 4

2

防御性编程与防御性驾驶一样合理。

从单独的关注点考虑这一点可能会有所帮助。一个问题是演示文稿。另一个可能是一组业务规则。在两个地方进行相同的检查是合理的。

您希望在表示层中进行检查以与用户进行通信。

您可能还想在表示层下方进行检查：

  • 防御表示层中现在和未来的错误。
  • 以防表示层下的代码在其他地方重用。
  • [来自 mvds 的评论] 如果启用或禁用控件后条件可能会发生变化。

编辑： David Heffernan 下面的 DRY 问题可以通过只定义一次条件并在其他地方访问它来轻松解决。

void setup_gui()
{
    some_button.setEnabled( context.isThisActionAvailable() );

    ...
}

void some_button_click()
{
    if ( context.isThisActionAvailable() )
        return;

   ...
}
于 2011-01-05T14:55:30.847 回答
1

我不采用这种皮带和大括号的方法。问题是你违反了 DRY 原则，双重使用 some_condition。在一个地方而不是另一个地方改变这一点很容易。

当然 some_condition 在这个虚构的示例中非常简单，但实际上它通常要复杂得多。

如果您在请求阻止操作时不能信任您的 GUI 框架来阻止操作，那么您需要修复框架。

于 2011-01-05T15:09:15.113 回答
0

无声返回some_button_click()可能隐藏了一个错误。我要么根本不做检查，要么大声而猛烈地崩溃。

于 2011-01-05T15:13:44.147 回答
0

它可以被认为是安全编码，也可以被认为是隐藏错误。这时候也许你应该重新评估你的程序逻辑。如果可能，最好避免代码冗余。如果您的程序的结构可以通过确保程序的实际逻辑按预期正常工作而无需检查两次，那就更好了。

当然，如果您很着急，这是一个快速修复方法并且它有效，但它散发出糟糕的设计和/或程序其他地方的逻辑。

于 2011-01-05T15:03:05.903 回答