问使用神奇的调试值(如0xDEADBEEF)作为文本究竟有什么危险？

EN

我相信今天早些时候在IP地址格式化问题中提出的关注与一般十六进制文字的使用无关，而与0xDEADBEEF的具体使用有关。至少我是这么看的。

尤其是使用0xDEADBEEF，我认为这是一个小问题。问题是，许多调试器和运行时系统已经将此特定值用作标记值，以指示未分配的堆、堆栈上的错误指针等。

我不记得是哪个调试和运行时系统使用了这个特定的值，但是这些年来我已经多次看到它这样使用了。如果您在这些环境中进行调试，代码中的0xDEADBEEF常量的存在将与未分配RAM中的值或其他值无法区分，因此充其量您将不会有那么有用的RAM转储，而且在最坏的情况下，您将收到调试器的警告。

无论如何，当他告诉你“在各种调试场景中使用”时，我认为这就是最初的评论的意思。

使用十六进制文字没有比任何其他类型的文字更危险。

如果调试会话最终以代码的形式执行数据，而没有打算执行数据，那么无论如何，您都处在一个痛苦的世界中。

当然，有一个正常的“魔术值”和“良好的常量”代码气味/清洁问题，但我认为这并不是真正的危险。

除了少数例外，没有什么是“不变的”。

我们更喜欢称它们为“慢变量”--它们的值变化太慢，以至于我们不介意重新编译来改变它们。

但是，我们不希望通过应用程序或测试脚本拥有许多0x07实例，其中每个实例都有不同的含义。

我们想在每一个常数上加上一个标签，使其完全明确它的含义。

if( x == 7 )

在上述声明中，"7“是什么意思？这是不是和

d = y / 7;

这就是"7“的意思吗？

测试用例是一个稍微不同的问题。我们不需要对数字文字的每个实例进行广泛、仔细的管理。相反，我们需要文件。

我们可以--在一定程度上--通过在代码中加入一点提示来解释"7“从何而来。

assertEquals( 7, someFunction(3,4), "Expected 7, see paragraph 7 of use case 7" );

一个“常数”应该说--并命名--准确地说一次。

单元测试中的“结果”与常量不是一回事，在解释它从何而来时，需要谨慎一点。