什么时候意外的功能是一个错误，或者只是糟糕的设计

Question

有时，程序员显然在他们的代码结构中做出了故意的选择，导致行为（充其量）不直观，但从技术上来说并不是一个错误，因为它被破坏了。这应该被归类为错误并修复吗？

例如，一个著名的开源电子商务系统（如果您查看我的回答历史记录，您就会知道是哪一个！）提供数量增量功能，管理员可以在其中指定必须添加到购物车的单位的倍数（例如必须是 5、10、15、20 等）。编写代码是为了仅当系统处于“管理库存”模式时（即库存水平随每个订单减少）才强制执行这些限制。现在，店主可能希望以指定的增量销售他们的产品，但不管理库存水平，这是一个完全有效的情况。该代码会默默地忽略配置（不会向管理员提供反馈），并且没有关于打开“管理库存”的要求的文档。

这是一个错误吗？或者只是糟糕的设计/文档。

请注意，我确信有些读者会将这个问题解释为主观的，但我认为错误和糟糕的设计之间存在重要的区别。这在开源项目中尤其重要，其中错误报告往往在与内部公司系统不同的流程中工作。

Answer 1

Bug 意味着行为与程序员的想法不同，而
糟糕的设计意味着程序员预期的行为超出了用户的合理预期。

Answer 2

是否有一个规范可以确定一种方法或另一种方法是否正确？如果有规范，那么它就是一个错误。

如果没有规范，那么它可能是糟糕的文档。

当代码默默地忽略配置时会发生错误吗？那么它就是一个错误。