在禁用的 GUI 选项中添加额外的检查是一个好习惯吗？
我指的是以下内容：
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() 必须根本没有运行）。
那么，您对此有何看法？这是安全的编码实践还是隐藏错误？
I'm referring to the following:
void setup_gui()
{
if (some_condition)
some_button.disable();
...
}
void some_button_click()
{
// Is this a good practice?
if (some_condition)
return;
...
}
Adding that check ensures that the program won't run the operation, but it can also be seen as hiding a bug (some_button_click() must not have run at all).
So, what do you think about it? Is it a safe coding practice or hiding a bug?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
防御性编程与防御性驾驶一样合理。
从单独的关注点角度来思考这一点可能会有所帮助。一个问题是演示。另一个可能是一组业务规则。在两个地方进行相同的检查是合理的。
您希望在表示层中进行检查以与用户进行通信。
您可能还想在表示层下方进行检查：
编辑： David Heffernan 的下面的 DRY 问题可以通过仅定义一次条件并在其他地方访问它来轻松解决。
Defensive programming is as reasonable as defensive driving.
It may be helpful to think of this in terms of separate concerns. One concern is the presentation. Another may be a set of business rules. It is reasonable to make the same check in both places.
You want to make the check in the presentation layer to communicate to the user.
You may also want to make the check below the presentation layer:
Edit: David Heffernan's DRY concern below can be addressed trivially by defining the condition exactly once, and accessing it elsewhere.
我不采用这种腰带和背带的方法。问题是你双重使用 some_condition 违反了 DRY 原则。在一个地方更改此设置非常容易，而在另一个地方则不然。
当然， some_condition 在这个虚构的示例中非常简单，但实际上它通常要复杂得多。
如果您不能相信 GUI 框架会在您请求阻止操作时阻止这些操作，那么您需要修复该框架。
I don't take this belt and braces approach. The problem is that you have violated the DRY principle with the double use of some_condition. It's all to easy to change this in one place and not the other.
Of course some_condition is quite simple in this made-up example but in reality it's often be much more complex.
If you can't trust your GUI framework to block actions when you request them to be blocked, then you need to fix the framework.
它可以被认为是安全编码，也可以被认为是隐藏错误。现在也许您应该重新评估您的程序逻辑。如果可能的话，代码冗余总是最好避免的。如果您的程序可以通过确保程序的实际逻辑正确且按预期工作而无需检查两次的方式构建，那就更好了。
当然，如果你很着急，这是一个快速修复并且它有效，但它在程序的其他地方散发着糟糕的设计和/或逻辑的味道。
It can be considered safe coding, it can also be considered hiding a bug. This is the time when perhaps you should re-evaluate your program logic. Code redundancy is something that is always best to avoid if possible. It would be better if your program could be structured in such a way that it would not need to check twice, by making sure the actual logic of the program works properly and as intended.
Sure, if you're in a rush this is a quick fix and it works, but it reeks of poor design and/or logic elsewhere in the program.
some_button_click()中的静默返回可能隐藏了一个错误。我要么根本不做检查，要么大声而猛烈地撞车。The silent return in
some_button_click()potentially hides a bug. I would either don't do the check at all, or crash loud and violently.