魔术数字是在代码中直接使用数字。

例如，如果你有(在Java中):

public class Foo {
    public void setPassword(String password) {
         // don't do this
         if (password.length() > 7) {
              throw new InvalidArgumentException("password");
         }
    }
}

这应该被重构为:

public class Foo {
    public static final int MAX_PASSWORD_SIZE = 7;

    public void setPassword(String password) {
         if (password.length() > MAX_PASSWORD_SIZE) {
              throw new InvalidArgumentException("password");
         }
    }
}

它提高了代码的可读性，也更容易维护。想象一下我在GUI中设置密码字段大小的情况。如果我使用一个神奇的数字，每当最大大小发生变化时，我必须在两个代码位置进行更改。如果我忘记了一个，就会导致不一致。

JDK中有很多例子，比如Integer, Character和Math类。

PS:像FindBugs和PMD这样的静态分析工具可以检测到代码中使用的神奇数字，并建议进行重构。

@eed3si9n:我甚至认为“1”是一个神奇的数字。: -)

与神奇数字相关的一个原则是，代码处理的每个事实都应该声明一次。如果您在代码中使用神奇的数字(例如@marcio给出的密码长度示例)，那么您很容易复制该事实，当您对事实的理解发生变化时，您就会遇到维护问题。

那么返回变量呢?

我发现在实现存储过程时尤其具有挑战性。

想象下一个存储过程(我知道语法错误，只是举个例子):

int procGetIdCompanyByName(string companyName);

如果该公司存在于特定的表中，则返回该公司的Id。否则，返回-1。 不知何故，这是一个神奇的数字。到目前为止，我读到的一些建议说，我真的必须设计这样的东西:

int procGetIdCompanyByName(string companyName, bool existsCompany);

顺便问一下，如果公司不存在，它应该返回什么?它会将existesCompany设为false，但也会返回-1。

Antoher的选择是做两个独立的功能

bool procCompanyExists(string companyName);
int procGetIdCompanyByName(string companyName);

因此第二个存储过程的先决条件是公司存在。

但是我害怕并发，因为在这个系统中，一个公司可以由另一个用户创建。

顺便说一句，最重要的是:你对使用这种相对已知和安全的“神奇数字”来判断某事不成功或某事不存在有什么看法?

魔术数字也可以是具有特殊的硬编码语义的数字。例如，我曾经看到一个系统，其中记录id > 0被正常对待，0本身是“新记录”，-1是“这是根”，-99是“这是在根中创建的”。0和-99将导致WebService提供一个新的ID。

这样做的不好之处在于，您重用了用于特殊功能的空间(记录id的有符号整数的空间)。也许您永远不希望创建ID为0或ID为负的记录，但即使不是这样，每个查看代码或数据库的人都可能在一开始无意中发现这一点并感到困惑。不用说，这些特殊的值并没有得到很好的记录。

可以说，22、7、-12和620也可以算作神奇数字。: -)

幻数是文件格式或协议交换开头的字符序列。这个数字可以作为一个完整性检查。

例子: 打开任何GIF文件，你会在最开始看到:GIF89。GIF89是一个神奇的数字。

其他程序可以读取文件的前几个字符，并正确识别gif。

危险在于随机二进制数据可能包含这些相同的字符。但这种可能性非常小。

至于协议交换，您可以使用它来快速识别正在传递给您的当前“消息”是否已损坏或无效。

神奇的数字仍然很有用。

在编程中，“神奇的数字”是一个值，它应该被赋予一个符号名称，但却被作为文字插入到代码中，通常在多个地方。

它不好的原因与SPOT (Single Point of Truth)好的原因是一样的:如果以后想更改这个常量，就必须遍历代码以找到每个实例。这也很糟糕，因为其他程序员可能不清楚这个数字代表什么，因此出现了“魔术”。

人们有时会进一步使用神奇数字消除，将这些常量移到单独的文件中作为配置。这有时是有帮助的，但也会带来更多的复杂性。