我最近遇到了这个编程习惯用法：

const float Zero = 0.0;

然后用于比较：

if (x > Zero) {..}

任何人都可以解释一下，这实际上是否比以下方法更有效，可读性或可维护性：

if (x > 0.0) {..}

注意：我可以想到定义此常量的其他原因，我只是想知道它在此上下文中的使用。

可能的原因是缓存，命名或强制类型

缓存（不适用）

您希望避免在比较过程中创建对象的成本。在Java中，一个例子是

BigDecimal zero = new BigDecimal ("0.0");

这涉及到相当繁重的创建过程，最好使用提供的静态方法来解决：

BigDecimal zero = BigDecimal.ZERO;

这允许进行比较而不会产生重复的创建成本，因为BigDecimal是在初始化期间由JVM预先缓存的。

就您所描述的而言，原语正在执行相同的工作。就缓存和性能而言，这在很大程度上是多余的。

命名（不太可能）

原始开发人员试图为整个系统中的通用值提供统一的命名约定。这有一些优点，特别是对于不常见的值，但是只有在较早的缓存情况下才值得像零这样的基本值。

强制类型（最有可能）

原始开发人员正试图强制使用特定的原始类型，以确保将比较强制转换为正确的类型，并可能转换为特定的比例（小数位数）。可以，但是对于此用例，简单名称“零”可能不够详细，因为ZERO_1DP是更合适的意图表达。

这是因为“工具Na”

我在这里未列出的可能原因是因为许多质量工具标记了幻数的使用。将幻数丢入算法中而又不使它们清晰可见以便以后更改通常是一种不好的做法，尤其是当它们在代码中的多个位置重复时。

因此，尽管这些工具在标记此类问题上是正确的，但对于这些值无害且最有可能是静态值或仅仅是初始化值的情况，它们通常会产生误报。

当发生这种情况时，有时您会面临以下选择：

• 如果工具允许，则将其标记为误报（通常带有特殊格式的注释，这对于不使用该工具的人来说很烦人）
• 或将这些值提取为常量，无论是否重要。

关于性能

这取决于我猜想的语言，但这在Java中相当普遍，并且对性能没有影响，因为如果值是实常数，则在编译时将其内联static final。如果将它们声明为常量甚至声明为预处理器宏，则对C或C ++不会产生影响。

这可能是有道理的，因为它明确定义Zero为type float。

至少在C和C ++中，值0.0是类型double，而等效值float是0.0f。因此，假设x您与之进行比较也是float一句话

x > 0.0

而实际上x要double进行推广以匹配0.0可能导致问题的类型（尤其是使用平等测试）。没有转换的比较当然是

x > 0.0f

与...相同

float Zero = 0.0; // double 0.0 converted to float  
x > Zero

尽管如此，我认为在编译器中启用转换警告而不是让用户编写笨拙的代码会更加有用。

首先，这里零定义为float，而不是int。当然，这对比较没有任何影响，但是在其他情况下，使用此常数可能会有所不同。

我看不出有其他原因为何Zero在这里声明为常量。这只是某种编码样式，如果在该特定程序的其他地方都使用该样式，则最好遵循该样式。

几乎可以肯定，它在执行期间的效率完全一样（除非您的编译器非常原始），而在编译期间的效率则略低。

关于这是否比x > 0... 更具可读性...请记住，有些人诚实，真诚地认为COBOL是一个好主意，并且很高兴与之合作—然后有些人对C的看法完全相同。甚至存在一些对C ++持相同观点的程序员！）换句话说，您在这一点上不会得到普遍的同意，这可能不值得为之奋斗。

[是]实际上，它比以下任何一种方法都更加有效，可读或可维护：

if (x > 0.0) {..}

如果您正在编写通用（即非特定于类型的）代码，那么很有可能。甲zero()函数可以适用于任何类型的代数，或者任何类型的是一组WRT加成。它可以是整数，也可以是浮点值，如果变量本身就是某个线性空间内的函数，则它甚至可以是一个函数（例如x是z-> a_x形式的线性函数* z + b_x），然后zero()为函数提供a和b均为zero()基础类型。

因此，您可能希望使用C ++（尽管zero()不是很常见的AFAIK），Julia和其他语言编写这样的代码。