滥用变量值？
我遇到过一个实例，其中特定问题的解决方案是使用一个变量，该变量的值为零或以上意味着系统将在计算中使用该值，但当小于零时则表明根本不应该使用该值。
我最初的想法是，我不喜欢变量值的多用途：a.) 作为公式中使用的范围； b.) 作为控制逻辑的一种形式。
这种变量的滥用叫什么？元“某物”或者是否有适合的经典反模式？
有点像当数据库字段设置为 null 时表示不使用值，如果它不为 null，则使用该字段中的值。
更新： 一个例子是，如果变量的值 > 0 如果该值 <= 0 我会使用该值，那么我不会使用该值并决定执行一些其他逻辑。
I came across an instance where a solution to a particular problem was to use a variable whose value when zero or above meant the system would use that value in a calculation but when less than zero would indicate that the value should not be used at all.
My initial thought was that I didn't like the multipurpose use of the value of the variable: a.) as a range to be using in a formula; b.) as a form of control logic.
What is this kind of misuse of a variable called? Meta-'something' or is there a classic antipattern that this fits?
Sort of feels like when a database field is set to null to represent not using a value and if it's not null then use the value in that field.
Update:
An example would be that if a variable's value is > 0 I would use the value if it's <= 0 then I would not use the value and decided to perform some other logic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
诸如此类的价值观通常被称为“杰出价值观”。到目前为止，最常见的区别值是引用类型的
null。紧随其后的是使用不同的值来指示异常情况（例如错误返回代码或搜索失败）。区分值的问题是所有客户端代码都必须知道这些值的存在及其关联的语义。实际上，这通常意味着必须在每个获取此类值的调用站点周围包含某种条件逻辑。很容易忘记添加该逻辑，从而获得不正确的结果。它还促进了复制粘贴代码，因为处理不同值所需的样板代码在整个应用程序中通常非常相似，但难以封装。
使用可区分值的常见替代方法是例外，或明确类型的值，这些值不会意外地相互混淆（例如，
Maybe或Option类型）。话虽如此，在内存可用性极其紧张或其他严格性能限制的环境中，区分值仍然可以发挥重要作用。
Values such as these are often called "distinguished values". By far the most common distinguished value is
nullfor reference types. A close second is the use of distinguished values to indicate unusual conditions (e.g. error return codes or search failures).The problem with distinguished values is that all client code must be aware of the existence of such values and their associated semantics. In practical terms, this usually means that some kind of conditional logic must be wrapped around each call site that obtains such a value. It is far too easy to forget to add that logic, obtaining incorrect results. It also promotes copy-and-paste code as the boilerplate code required to deal with the distinguished values is often very similar throughout the application but difficult to encapsulate.
Common alternatives to the use of distinguished values are exceptions, or distinctly typed values that cannot be accidentally confused with one another (e.g.
MaybeorOptiontypes).Having said all that, distinguished values may still play a valuable role in environments with extremely tight memory availability or other stringent performance constraints.
我不认为你的描述是一个纯粹的魔法数字，但是有点接近。这与 .NET 2.0 之前版本中的情况类似，您可以使用 Int32.MinValue 来指示空值。 .NET 2.0 引入了 Nullable 并在一定程度上缓解了这个问题。
因此，您正在描述变量的使用，该变量的值实际上意味着除其值之外的其他东西 -1 的含义与我上面描述的 Int32.MinValue 的使用基本相同。
我称其为神奇数字。
希望这有帮助。
I don't think what your describing is a pure magic number, but it's kind of close. It's similar to the situation in pre-.NET 2.0 where you'd use Int32.MinValue to indicate a null value. .NET 2.0 introduced Nullable and kind of alleviated this issue.
So you're describing the use of a variable who's value really means something other than it's value -- -1 means essentially the same as the use of Int32.MinValue as I described above.
I'd call it a magic number.
Hope this helps.
当数据和程序代码的 RAM 和磁盘空间稀缺时，使用变量的不同可能值范围来调用不同的功能是很常见的。如今，您可以使用函数或附加的伴随值（布尔值或枚举）来确定要采取的操作。
当前操作系统建议 1GiB RAM 才能正常运行，而几年前 256KiB 还很高。廉价的磁盘空间在短短几个月内就从数百 MiB 增加到数倍 TiB。不久前，我为 640KiB RAM 和 10MiB 磁盘编写了程序，您可能会讨厌它们。
我认为，如果这样的代码只有几年的历史（重构它！），那么最好处理它，如果它是最近的，则谴责它是不好的做法。
Using different ranges of the possible values of a variable to invoke different functionality was very common when RAM and disk space for data and program code were scarce. Nowadays, you would use a function or an additional, accompanying value (boolean, or enumeration) to determine the action to take.
Current OS's suggest 1GiB of RAM to operate correctly, when 256KiB was high very few years ago. Cheap disk space has gone from hundreds of MiB to multiples of TiB in a matter of months. Not too long ago I wrote programs for 640KiB of RAM and 10MiB of disk, and you would probably hate them.
I think it would be good to cope with code like that if it's just a few years old (refactor it!), and denounce it as bad practice if it's recent.