代码之家 › 专栏 › 技术社区 › nickf

何时使用常量作为参数而不是魔力值

constants parameters

nickf · 技术社区 · 15 年前

我已经读到(并且大体上同意)为了提高代码易读性,应该使用常量而不是幻数作为方法参数。例如,使用php:

// no constants ////////////////////
function updateRecord($id) {
    if ($id == -1) {
        // update all records
    } else {
        // update record with "id = $id"
    }
}

updateRecord(-1); // future maintainer says: "wtf does -1 do?"
                  // and then has to jump to the function definition

// with constants: /////////////////

define('UPDATE_ALL', -1);

function updateRecord($id) {
    if ($id == UPDATE_ALL) {
        // update all records
    } else {
        // update record with "id = $id"
    }
}

updateRecord(UPDATE_ALL); // future maintainer says: "woot"

_{是的,这不是一个很好的例子,我知道…}

所以,我可以看出这是一件更好的事情,但它提出了这样做的频率的问题?如果它适用于每个函数,那么最终会得到一个常量定义的度量范围。

你要在哪里画线? 一直坚持使用常量,还是根据所讨论函数的用法采用混合方法?

5 回复 | 直到 11 年前

Daniel Schneller 15 年前

正如您已经指出的,未来的维护人员将感谢您明确的命名。这个维护者甚至可能是你,我一次又一次地惊讶于我忘记了我自己的代码,当我已经有一段时间没有在代码上工作的时候,再次理解它是多么的困难。

我肯定会一直使用常量,只要范围大于一个简单的方法。一旦开始传递这些值,imho必须将它们定义为常量。在方法内部,注释可能会执行此操作。但是,这并不能帮助代码中没有看到该注释的任何调用方。即使是同一类中的另一个方法也应被视为“API客户机”,它不应该知道它在这方面调用的其他方法的实现细节。

使用支持“真实”枚举的语言(如Java) enum 关键字在Java 5中引入)甚至可以获得类型安全性,并且不承担例如基于整数的常量可能存在的唯一性问题。

Anon. 15 年前

所以,我可以看出这是一件更好的事情,但它提出了这样做的频率的问题?如果它适用于每个函数,那么最终会得到一个常量定义的度量范围。

如果每个函数都采用“魔力参数”,那么 你已经大错特错了 .

我愿意总是使用常量。如果你认为这意味着你有太多的常量,那么这只是反映了你设计中的其他缺陷。

alex 15 年前

我会在哪里用它……

提高可读性
帮助你记住
让我们看看一瞥你所传递的论点

以PHP为例 sort() 例如。这是有道理的:

sort($array, SORT_NUMERIC);

但是会这样吗?

sort($array, 2); // Haven't actually dug in to see what it matches, but you get the point

prodigitalson 15 年前

如果你在类中包装东西,并且使用类常量,那么问题就少了。除了路径之外,我很少使用全局常量。

Vector 11 年前

您应该尽量将代码中的文本保持在绝对的最低限度:每个文本都是一个潜在的问题,因为您的环境可以更改,而且其他开发人员可能不知道它的含义。

当我开始一个项目时,我总是将一个文件专门用于命名常量,通常被包装在一个专门用于命名常量的类中,并且由于我工作的性质需要,我对它们进行了大量的使用。所有命名常量都驻留在该文件中,并由该文件控制,从而为您提供了出色的组织和对命名常量的控制。您还可以将它们组织成带有注释或代码区域的组,并且根据语言的不同,将它们一个嵌套并构建在另一个组上。

这些年来,这种做法帮助了我无数次。