14

我想知道使用腰带和大括号（吊带）方法进行编程 - 尤其是数据验证 - 是否是一种好习惯。这来自以下示例。

我正在创建一个表单，并向所有字段添加了侦听器，这意味着OK只有在表单中的所有字段都具有有效值时才启用该按钮。然后我正在编写OK单击按钮时运行的代码。

我悲观的一面认为，Belt and Braces 永远不会伤害任何人，如果我的表单逻辑出现错误，再次验证表单也无妨。

但是，如果验证失败，我不知道要输入什么。如果我做这样的事情：

if (! form.isValid()) {
  displayErrorMessage();
}

然后我必须创建代码来显示不应该显示的错误消息。将来维护此代码的任何人都会担心并且可能会对此在理论上不必要的对话感到困惑。我想要的最后一件事是有人想知道为什么这个特定的对话框从不显示。

规模的另一端的一个选项是：

if (! form.isValid()) {
  throw new RuntimeException("This should never happen!");
}

坦率地说，即使打字我也觉得很脏，但也许有一个很好的理由使用它，但我错过了。

所以最后我结束了：

assert form.isValid();

然而，它的缺点是它不是真正的腰带和大括号，因为大括号在运行时不存在，所以如果代码中有错误，我的表单的裤子仍然会掉下来。

所以也许我根本不应该有额外的验证，但我仍然有一部分认为它不会受到伤害。

我很想听听你在类似情况下会做什么。

（编辑：问题是问什么是确保表单返回有效数据的最佳方法。假设表单的输出在它最终进入数据库之前再次验证等等。）

4

9 回答 9

5

我没有做太多的 UI 工作，但最近我发现自己在做一些非常相似的事情。我留下了腰带（在每个控件更改时验证它）和大括号（在 OK_Click 上再次检查有效）。

我将两者都保留的基础是，如果将来某些更改错过了控件上的验证，则单击“确定”按钮时会被捕获。

在我看来，对 OK 的检查是真正的验证，而每个控件的验证是只是增强用户体验的糖。

也就是说我没有想太多，也不经常做UI工作。

于 2009-04-20T12:07:19.703 回答
5

根据我的经验，“以防万一”代码有时是懒惰编程的症状。即，我找到了一个基本可行的解决方案，但我不确定它是否会一直有效，所以我会输入一些双重检查代码“以防万一”。如果您不将火箭飞船送上月球，这种类型的事情相对无害，但仍然可能是非常糟糕的做法。

对于我的（非火箭式）业务应用程序，我总是输入错误日志和友好消息，并尝试从头到尾思考问题，以便用户尽可能少地看到友好消息。如果有问题，我能够更好地解决它，因为我的代码不会被各种不必要的检查弄得一团糟。

于 2009-04-20T13:05:41.857 回答
1

我的同事通常会双重验证输入，“以防万一”。我认为这在很大程度上取决于与您一起工作的人或必须维护您的代码的人。如果你总是重复验证，他们会很快了解你在做什么。如果您有时只进行双重验证，他们可能会感到困惑。也许您应该向同事咨询他们的习惯？如果您单独或在一个非常小的团队中工作，则可能可以双重验证您的输入。

如果我要接管你的代码，我认为重要的事情可能是遵循一个约定，要么总是要么永远不会在两个地方都进行验证。至少这样我就不会糊涂了。

编辑：就网络编程而言，javascript 通常用于在将输入发送到服务器之前进行验证。显然，这还不够，因为用户可以关闭 javascript 并绕过该验证，因此在这种情况下需要服务器端验证。在任何情况下，如果用户可能恶意或意外绕过验证的第一行，还必须对后端进行仔细检查。我想这在 Java、C# 等中不是问题。

于 2009-04-20T12:04:14.877 回答
1

我还要说双重验证永远不会伤害任何人，只会增加安全性。

我还想就您的业务逻辑提出一点意见。我假设这是一个 Winforms 应用程序，但该原理也适用于 Web。UI 不应强制执行业务逻辑。将验证放在那里很好，但它也需要在业务逻辑中。

于 2009-04-20T12:11:11.893 回答
1

无论您决定做什么，只要确保记录意外状态并使程序以某种方式失败以防止数据损坏。就我个人而言，我认为这对于我不期望出现错误的情况是必要且足够的。

于 2009-04-20T12:13:39.750 回答
1

在网络（没有双关语）编程中，总是会采用这种方法，因为您不能依赖实际运行的客户端验证；狡猾的用户可以构建一个表单帖子或 URL 来模拟您的客户端并将数据发送回服务器。

在独立应用程序中，它不太清楚。我建议这取决于验证发生的位置。例如，如果您的验证在您的业务逻辑中运行，而不是在您的 UI 中，那么您的验证应该每次都运行。使用关注点分离，业务逻辑不应该依赖 UI 来进行验证。毕竟，可以从典型的 GUI、Web 应用程序甚至 API 调用业务逻辑。

我建议的一件事是，在 UI 中将验证逻辑加倍可能是矫枉过正——但您应该能够处理来自底层的错误。在这种情况下，错误可能来自验证。

于 2009-04-20T12:15:07.173 回答
1

我建议从纯粹的可用性角度来看待这个问题。您的用户在填写表单时应该如何工作？大多数时候，我建议在控件和表单级别进行验证。当然，您可以使用多种用户交互方式：

  1. 让用户为所欲为，然后在 OK 上检查他们的结果。这对于专家用户来说非常棒，允许他们快速、渐进地输入内容，但让新手和不经常使用的用户不知所措。
  2. 在输入或离开时验证每个控件。这可能很好，特别是对于复杂的形式（当然我们不应该设计，永远，真的，但是......！）；但做得不好会阻止人们按照自己的顺序逐步填写表格。如果我这样做，我更喜欢视觉上的指示，表明有什么不对劲。
  3. 让输入任何错误的东西都不可能。这可以（几乎）通过例如数字滑块、受限标量的组合框、防止错误条目的自动验证编辑框来实现。

但是，即使在第 3 种情况下，在某些情况下您也必须检查值的组合是否有效。我曾处理过一些控件子集中的值相互依赖（由方程式控制）的情况。在这些情况下，向用户提供即时反馈并不总是可行或值得付出努力，因此始终可以制作一个案例来验证 OK。

我同意 Binary Worrier 的观点，即 OK 检查是主要检查。如果您确定它永远不会失败，请确保在触发时记录警告，并尽可能通过您的支持渠道嗅探此类事件，但不要让最终用户为编程错误付费。

于 2009-04-20T13:17:11.783 回答
1

我将给出一个非常不受欢迎的答案。

我的回答是：视情况而定。

在人们开始愤怒地从椅子上站起来并为他们的拿铁咖啡添加额外的泡沫之前，请听我说完。 一个愤怒的程序员敲打屏幕

我修改了一个使用共享文件的 ERP 包。别笑，这是日常工作。无论如何，该系统在设计中存在一个缺陷——它在输入时验证数据，然后由于一次性验证，一旦它写出记录，它总是假设它是正确的。

这听起来是一种合理的方法，直到您遇到丢失的数据字段、崩溃的会话、您看不到的 RAM 损坏的机器、未检测到的 LAN 连接不稳定的机器，以及编程语言本身中偶尔出现的错误（或两个） . 记录写了一半，字段可能会丢失数据，索引偶尔会无缘无故地崩溃......这个列表还在继续。

现在，提供软件的供应商在很大程度上与束手无策的人竞争，因为，嘿，时间就是金钱，而且他们的业务是销售他们的产品（软件）。每 15 分钟编写额外的健全性检查就是 15 分钟可以用来产生收入。 但是他们不会在凌晨 3 点被寻呼来修复崩溃的会话或释放令人讨厌的死锁。我愿意。

因此，我在我编写的过程、函数和方法中添加了断言的粗略等价物。我对传递的数据类型进行健全性检查（它使所有变量变体），尽可能交叉引用数据，并在代码中寻找其他“精神错乱”的迹象。当例程发现类似于暮光区的东西时，它会给出一个诊断对话框（用户通常会截屏并转发给我），然后尝试优雅地失败；如果不能正常失败，用户通常会看到保存进度并注销的说明。

这是腰带和吊带吗？ 是的。 我喜欢这样做吗？ 不。 它是否在许多场合拯救了我的理智、睡眠时间和培根？

是的。哦是的...

所以，如果你有一个“敌对”的编程环境，你不能总是相信输入到你的代码中的数据，那么嵌入各种健全性检查是合理的......一直保持安全带和吊带.

否则，它是不需要的。

于 2015-08-21T17:45:18.127 回答
0

我认为皮带和背带不是一个好习惯。

如果需要极高的可靠性，例如飞船软件，那么保证它的方法是提供多个并行运行的不同实现，都提供相同的输入，并且都期望提供相同的输出。显然，那不是腰带和牙套，而是别的东西。

如果极端可靠性不是问题，那么皮带和背带实际上只会以您自己发现的方式使事情复杂化。

您最终得到的断言是最好的做法，因为断言旨在捕获错误并记录代码，而这正是当前情况发生的情况：如果表单在您的点无效断言，那么您在表单的其他地方有一个错误，并且断言本质上是在记录这样一个事实，即在您的代码中，您希望表单的有效性已经得到处理。此外，应该在应用程序的测试阶段消除此错误发生的可能性，因此它不应该在生产中发生，这再次符合断言的目的和预期用途。

如果您真的喜欢皮带和大括号范式，那么您仍然可以将断言视为皮带和大括号方案的一部分，但在正确的上下文中：测试。这个断言在测试期间是束手无策的，因为它保证您在代码的其他地方完成了所有正确的测试。

于 2014-12-23T14:55:52.413 回答