“ x和y之间”应该交换吗？

26

在我的应用程序中，有一些预定义的表达式模板可用于过滤数据。其中之一是“ between x and y”。一位质量检查工程师声称其定义存在缺陷，因为“ between 100 and 200”与“ ”给出的结果不同between 200 and 100。该表达式在内部转换为“ value >= x and value <= y”，因此，当第二个边界低于第一个边界时，显然没有结果。我检查了SQL是否存在相同的行为-“ between x and y”假定y> = x或没有结果。这意味着，至少在SQL中，运算符不是可交换的。

那么，质量保证“ between x and y”应可交换吗？

requirements

— pkalinow
source

11

否，但是当有人输入错误时，您的用户界面可能会变成红色。

— 伊万

3

另外，它>> <=之一应该是排他性的，这样您就可以链100-> 200 200-> 300等而不会出现重叠

— Ewan

23

目前尚不清楚是否between应包含或排除较低和较高的值。质量检查人员可能是个书呆子，但只要不确定，就需要澄清用户案例/要求。可能会发现，完成它们的方式是应该的方式，但是必须做出决定。

— 弯曲

11

这不是对与错的情况。这是一种情况...企业希望应用程序如何运行？答案是期望什么功能。技术辩论不会推动所需的功能。所需功能推动了技术辩论，并有望激发出最佳业务解决方案。

— 布拉德·托马斯

2

这个问题更多的是关于用户的期望，而不是程序员的期望。这样，在用户体验上更合适。

— Makyen's

32

如果您当前的规格未定义，则行为完全是任意的，没有“正确”或“错误”定义。因此，如果您的质量检查工程师无法将您指向规范中定义此行为的确切段落，您可能会拒绝他的要求（尽管这似乎不是一项要求，但需要付出很多努力才能实现）。如果双方都无法达成共识，则团队中的一个人必须做出决定，在应用程序的上下文中，什么才是更重要的：

尽可能遵循SQL标准
由于人体工程学，特定用例或其他要求而未遵循

无论您的团队做出什么决定，最好记录一下行为和做出决定的原因。

— 布朗博士
source

57

您可能会拒绝他的请求 =>实际上，我首先要说的是，应该定义行为。然后，您可以感谢质量检查人员指出的问题，并说现在已指定它以<特定方式>起作用（并确保代码与规范匹配）。

— Matthieu M.

1

@MatthieuM。我认为这是一个单独的答案，应该自己进行33次投票。;）

— jpmc26

1

将错误转换为改进，并将其永久保留在积压中。感谢质量检查人员的努力。

— 桑迪·查普曼

1

@MatthieuM。是的，在理想世界中，每个细节都会有明确的要求。在这种情况下，我不需要在Stack Exchange上提问：）

— pkalinow

@pkalinow：我认为您误解了我的评论。我的观点是，在关闭该错误之前，您应该（1）感谢质量保证人员指出了一段未指定的代码，以及（2）与有兴趣实际指定行为的人员坐在一起。这可能意味着将质量检查报告分配给负责编写规范的人员，如果您有这样的事情，则分配给产品所有者等。然后，一旦行为应被同意，您就可以评估软件是否需要更改或不。也许就意味着要更改软件，也许就意味着要关闭报告……

— Matthieu M.

13

这是一个可用性或用户体验问题。SQL或任何其他系统的行为方式无关紧要，问题是从用户角度来看最有意义的是什么。

从用户角度来看，当前行为没有任何意义。或者，x和y应该是可互换的，或者它不应该被允许选择的x比y大。允许x大于y但返回空集会带来不必要的错误可能性，而不会带来任何好处。

因此，质量检查工程师是正确的，但有缺陷，但是提出的解决方案不一定是最好的。您必须执行可用性测试来确定这一点，或者至少要问一些有代表性的用户对他们来说最自然的是什么。

或者，您可以在/ux//上提问。那里的人们实际上了解用户体验的一两件事。

— 雅克
source

11

有几个明智的选择，具体选择取决于系统的其余部分以及用户的期望。

正如质量检查工程师指出的那样，您可以使表达式可互换，然后将其翻译为

between x and y => value >= min(x, y) and value <= max(x, y)

您可以将有效用法限制为x <= y，这需要您的UI尽可能早地显示“那不是有效的表达式”。

作为上述方法的一种变体，x < y如果您有表达式equals x并且希望使用表达式来限制，则限制value >= x and value <= x

— 卡雷斯
source

注意：请不要发表声明本身value >= min(x, y) and value <= max(x, y)。预先计算可以为数据库服务器节省工作的内容，尤其是在这种多余的情况下（您可以执行一次相关操作，并相应地设置两个结果）。可能无关紧要，具体取决于数据库服务器和您要输入的特定值，但是编写不佳的SQL Server可能会对每条记录执行，如果将它们放在中，并且可以省去这些工作，那么它们可能会很好地执行min和max。，没有理由不这样做。where

— 基金莫妮卡的诉讼

6

请不要听QPaysTaxes-在不衡量必要性的情况下优化事物正是Knuth所说的“过早优化是万恶之源”。在大多数现实世界代码中，如果为每条记录计算Min和Max时，您不会注意到速度上的差异，但是预先计算值（并因此引入额外的代码和额外的冗余）将使程序的可维护性大大降低。

— 布朗

@DocBrown我同意，如果不进行衡量，我们不应该为潜在的性能提升做出更改，但是与您的主张相反，我会发现预先计算的界限比单线更易读，因此更易于维护。

— Jacob Raihle

@JacobRaihle：这可能是有道理的，但就我的口味而言，value >= min(x, y) and value <= max(x, y)它与一样可读value >= minXY and value <= maxXY，其中minXY和maxXY是预先计算的界限。但是，对于后者，将不得不编写一些代码以将这两个新变量添加到系统中，并预先填充它们，不要忘记在x和y更改时更新这些值，依此类推。冗余数据总是会带来一定的错误风险。

— 布朗

5

在非交互式设置中，您的边界是由脚本创建的，通常有必要要求它们井井有条。这样可以减少要做的验证检查，从语义上讲更有意义，并且管理起来很简单。

在交互式设置中，您想帮助用户。如果可能，请制作一个不允许输入交换范围的GUI，或者至少使其尽可能容易地按顺序输入范围。如果要通过文本输入范围，请从vim上获取可用性的典范，然后提示用户自动交换反向范围：

Backwards range given, OK to swap (y/n)?

如果您的QA工程师没有任何方法可以通过UX来显示反向范围，那么他将做出合理的假设。

— 卡尔·比勒费尔特
source

2

坦白地说？不要使用“之间”。完全没有

首先，该术语非常难以理解，尤其是在英语中。是可交换的吗？这些条款是否专有？包括的？

其次，如果您正在做的是与后端分离的接口，请不要担心后端的行为。也不要让您的用户承担继承的行为。当然，SQL将其定义BETWEEN为包含性，但这几乎绝不是所希望的行为（例如-如果您执行类似的操作rows BETWEEN :start and :start + :stride将要获得stride + 1行）。

相反，您应该显式列出端点的比较。“大于或等于x”。“今天之前”。这消除了歧义。它还有助于编写更简洁的代码，并避免一些隐患。前面的行示例本质上是Djikstra的有关indexing的帖子。并且允许SQL在某些类型上使用包含性上限会导致选择错误的数据。

— 发条缪斯
source

好吧，值得思考。并感谢您的链接。Dijkstra的帖子可能不太相关，但很有趣：)

— pkalinow

这并不能真正回答OP问题，反而增加了混乱。

— 罗兰·德普

1

与您的质量检查人员争论谁是“正确的”和谁是“错误的”是没有用的。您对规范的理解与他们的理解不同。这意味着该规范非常含糊，需要澄清。

如果用户界面是规范，而不是质量检查人员期望的行为，那么它就不会是至少某些用户期望的行为。这表明了可用性问题（即使您想争论PEBKAC）。与您的质量检查人员一起找到令人满意的解决方案。

一般而言，请小心使用“之间”之类的词，这些词看似清楚，但不清楚。除了您对是否应该上下班不满意外，它们在两端都存在包容性问题，并且可能在直觉上意味着不同领域的不同情况（例如，“星期五和星期一之间”对于大多数人而言意味着不同于“星期一和星期五之间”）。星期五”）

— 马丁
source

1

我将介绍讨论简单接口的UNIX原则。

无论您在哪里提供与外界的接口，都应使事情尽可能地令人惊讶！

现在，我已将问题陈述简化为更实际的陈述，我想您只需花一点时间就可以意识到，在指定数字范围时，将较小的陈述保留为前者是显而易见的。如果这仍然是一个难题，请这样想-您告诉孩子如何比较两个数字时，您使用了相反的方式来表示两个数字？

如果您的质量检查工程师将其称为错误，请礼貌地告诉他您正在期待一些真正的错误，而不是将琐碎的精力浪费在琐碎事情上的方法。

— an4
source

0

每当调试代码以错误的顺序传递值时，使调试代码抛出错误条件或记录警告。这样，如果需要，调用代码可以检查和交换参数。这样，具有此“功能”的用户将意识到并做正确的事（您事先不知道）。

— 格里马尔迪
source