推荐的数字初始化值
假设您有各种基于数字或 int 的变量，您希望将它们初始化为某个默认值。 但使用 0 可能会出现问题，因为 0 有意义并且可能会产生副作用。
对此有什么约定吗？
我最近一直在使用 Actionscript，并且有各种带有可选参数的值对象，因此对于大多数变量我设置为 null，但对于数字或整数我不能使用 null。 一个例子：
package com.website.app.model.vo
{
public class MyValueObject
{
public function MyValueObject (
_id:String=null,
_amount:Number=0,
_isPurchased:Boolean=false
)
{ // Constructor
if( _id != null ) this.id = _id;
if( _amount != 0 ) this.amount = _amount;
if( _isPurchased != false ) this.isPurchased = _isPurchased;
}
public var id:String;
public var amount:Number;
public var isPurchased:Boolean;
}
}
困难在于，如果该值从未从其初始值更改，那么在上面的代码中使用 0 可能会出现问题。 很容易检测变量是否具有空值。 但检测 0 可能并不那么容易，因为 0 可能是合法值。 我想设置一个默认值以使参数可选，但我还想稍后在代码中检测该值是否从默认值更改而不会产生难以调试的副作用。
我想我可以使用 -1 之类的值。 我想知道这种事情是否有任何众所周知的编码约定？ 我想这取决于变量和数据的性质。
这是我的第一个堆栈溢出问题。 希望我的问题的要点是有意义的。
Assume you have a variety of number or int based variables that you want to be initialized to some default value. But using 0 could be problematic because 0 is meaningful and could have side affects.
Are there any conventions around this?
I have been working in Actionscript lately and have a variety of value objects with optional parameters so for most variables I set null but for numbers or ints I can't use null. An example:
package com.website.app.model.vo
{
public class MyValueObject
{
public function MyValueObject (
_id:String=null,
_amount:Number=0,
_isPurchased:Boolean=false
)
{ // Constructor
if( _id != null ) this.id = _id;
if( _amount != 0 ) this.amount = _amount;
if( _isPurchased != false ) this.isPurchased = _isPurchased;
}
public var id:String;
public var amount:Number;
public var isPurchased:Boolean;
}
}
The difficulty is that using 0 in the above code might be problematic if the value is not ever changed from its initial value. It is easy to detect if a variable has a null value. But detecting 0 may not be so easy because 0 might be a legitimate value. I want to set a default value to make the parameter optional but I also want to later detect in my code if the value was changed from its default without hard to debug side affects.
I suppose I could use something like -1 for a value. I was wondering if there are any well known coding conventions for this kind of thing? I suppose it depends on the nature of the variable and the data.
This is first my stack overflow question. Hopefully the gist of my question makes sense.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
许多调试器会使用 0xdeadbeef 来初始化寄存器。 当我看到这个的时候我总是会心一笑。
但是，老实说，您的问题包含自己的答案 - 使用您的变量永远不会预期的值。 价值是多少并不重要。
A lot of debuggers will use 0xdeadbeef for initializing registers. I always get a chuckle when I see that.
But, in all honesty, your question contains its own answer - use a value that your variable is not ever expected to become. It doesn't matter what the value is.
既然你在评论中提出了这个问题，我就谈谈 C 和 C++ 吧。 出于效率原因，默认情况下不会初始化局部变量和分配的内存。 但调试版本通常这样做是为了帮助捕获错误。 使用的常见值是 0xcdcdcdcd，这是相当不可能的。 它具有高位设置，并且是相当大的无符号数或相当大的负符号数。 作为一个指针地址，它很奇怪，如果用在除 char 之外的任何东西上（但不是在 X86 上），将会导致对齐异常。 作为 32 位浮点数，它没有特殊含义，因此它不是一个完美的选择。
有时，您会在变量中看到部分对齐的值，例如 0xcdcd0000 或 0x0000cdcd。 这些至少可以被视为可疑。
有时根据库的分配区域会使用不同的值。 这为您提供了错误值可能源自何处的线索（即，它本身没有初始化，而是从未初始化的值复制而来）。
无论您从内存中读取什么对齐方式，理想值都是无效的，并且对于所有基元类型都是无效的。 它对于人类来说也应该看起来很可疑，所以即使他们不知道约定，他们也可以怀疑某物是脚。 这就是为什么 0xdeadbeef 可能是一个不错的选择，因为（十六进制查看）程序员会认为这是人类的工作而不是随机的机会。 另请注意，它很奇怪并且设置了高位，因此它有这样的作用。
Since you asked in a comment I'll talk a little bit about C and C++. For efficiency reasons local variables and allocated memory are not initialized by default. But debug builds often do this to help catch errors. A common value used is 0xcdcdcdcd which is reasonably unlikely. It has the high bit set and is either a rather large unsigned or rather large negative signed number. As a pointer address it is odd which will cause an alignment exception if used on anything but a char (but not on X86). It has no special meaning as a 32 bit floating point number so it isn't a perfect choice.
Occasionally you'll see a partially aligned value in a variable such as 0xcdcd0000 or 0x0000cdcd. These can be treated as suspcious at the very least.
Sometimes different values will be used depending on the allocation area of library. That gives you a clue where a bad value may have originated (i.e., it itself wasn't initialized but it was copied from an unititialized value).
The ideal value would be invalid no matter what alignment you read from memory and is invalid over all primitive types. It also should look suspicious to a human so even if they do not know the convention they can suspect something is a foot. That's why 0xdeadbeef can be a good choice because the (hex viewing) programmer will recognize that as the work of a human and not random chance. Note also that it is odd and has the high bit set so it has that going for it.
值
-1传统上通常用作“超出范围”或“无效”值来指示失败或未初始化的数据。 话又说回来，如果 -1 是变量的语义上有效的值……或者您使用的是无符号类型，那么这一切都会发生。The value
-1is often traditionally used as an "out of range" or "invalid" value to indicate failure or non-initialised data. Then again, that goes right down the pan if -1 is a semantically valid value for the variable...or you're using an unsigned type.您似乎喜欢
null（并且有充分的理由），那么为什么不直接使用它呢？You seem to like
null(and for a good reason), so why not just use it throughout?在 ActionScript 中，只能将 Number.NaN 分配给类型为 Number 的变量，而不能分配给 int 或 uint。
话虽这么说，因为 AS3 不支持命名参数，所以您始终可以查看参数数组（它是所有函数都具有的内置数组，除非您使用 ...rest 构造）。 如果该数组的长度小于数字参数的位置，您就知道它没有被传入。
In ActionScript you can only assign Number.NaN to variables that are typed Number, not int or uint.
That being said, because AS3 does not support named arguments you can always look at the arguments array (it's a built-in array that all functions have, unless you use the ...rest construct). If that array's length is less than the position of your numeric argument you know it wasn't passed in.
我经常为此使用最大值。 正如您所说，零通常是一个有效值。 一般来说 max-int 虽然理论上有效，但可以安全地排除。 但不总是; 当心。
I often use a maximum value for this. As you say, zero often is a valid value. Generally max-int, while theoretically valid, is safe to exclude. But not always; be careful.
我喜欢 0xD15EA5ED，它与 0xDEADBEEF 类似，但在调试时通常更准确。
I like 0xD15EA5ED, it's similar to 0xDEADBEEF but is usually more accurate when debugging.