何时使用哨兵值？
我最近不得不使用 GPS 位置 API，其中每个位置对象都有两个属性 altitude 和 verticalAccuracy。负的 verticalAccuracy 表示 altitude 无效，而通常较小但正的 verticalAccuracy 值实际上意味着 altitude更精确（因为它是可能偏离的垂直距离 - 我将留下关于为什么此测量被称为 verticalAccuracy 而不是其他一些测量的 verticalInaccuracy 的讨论 时间）。
这让我开始思考：什么时候像这个 API 那样使用哨兵值是个好主意，什么时候最好显式创建一个单独的 hasValidAltitude 属性？还有其他选择吗？
I recently had to use a GPS location API where each location object had among other things two properties altitude and verticalAccuracy. A negative verticalAccuracy signifies that altitude is invalid, whereas normally a smaller but positive value of verticalAccuracy actually means that altitude is more precise (since it's the vertical distance that it may be off by - I'll leave the discussion as to why this measure is called verticalAccuracy and not verticalInaccuracy for some other time).
This got me thinking: When is it a good idea to use sentinel values like this API does and when would it be better to explicitly make a separate hasValidAltitude property? Are there other options?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
有时，哨兵答案实际上是不可能的；也许函数的范围与余域（范围）一致。高度则不然，除非你允许负高度（也许将来会有水下城市）。例如，也许我们正在谈论线之间的交集（这不是一个很好的例子，因为浮点有一些内置标记，如 +INF 和 NaN）或精确的整数商（没有舍入，这不能保证存在...例如7和3...这里，除法后的余数可以被视为标记或“精确整数商存在”属性）。更一般地，任何可靠的哨兵都可以简单地用于构建基于属性的机制。
基于此，我建议在可能且有意义的情况下避免使用哨兵。我的理由是它们是模块的内部实现细节，应该封装在信息隐藏接口后面。
Sometimes, sentinel answers aren't really possible; maybe the function's range coincides with the codomain (range). This isn't the case with altitude, unless you allow negative altitudes (maybe in the future, there will be underwater cities). For instance, maybe we're talking about the intersection between lines (not a great example, since floating-points have a few built-in sentinels like +INF and NaN) or the precise integer quotient (without rounding, this is not guaranteed to exist... 7 and 3, for instance... here, the remainder after division can be viewed as either a sentinel or a "exact integer quotient exists" property). More generally, any reliable sentinel can be trivially used to construct a property-based mechanism.
Based on this, I'd recommend avoiding sentinels wherever this is possible and makes sense. My reasoning is that they are an internal implementation detail of the module, and should be encapsulated behind an information-hiding interface.