类似常量的变量命名规范

约定俗成只是约定俗成，它们的存在是为了帮助代码更易于理解。如果它们选择得不太糟糕并且一贯地应用，通常会起到这个作用。最后一个点可能是关于它们最重要的事情：它们应该一致地应用。

有一件事情阻止了一些约定即使一贯地应用也无法使代码更易读 - 至少对于新手和在不同代码库之间切换的人来说 - 那就是当它们与其他约定冲突时。在 C 和 C++ 中，我知道两个关于使用 ALL_CAPS 名称的常见约定：

• 将它们保留给预处理器；我偏好这个，因为预处理器标识符很特殊：它们不遵守通常的作用域规则，防止与它们发生冲突很重要

• 将它们用于常量（宏和枚举器）。

除了不熟悉之外，如果您将它们用于逻辑上的常量但实际上是变量的东西，还会出现两个问题：

• 它们不能在语言期望常量表达式的地方（如数组大小）使用

• 我的经验告诉我，维护将倾向于使它们比现在更不稳定。

提供错误信息通常不是最佳实践。

暗示某些东西是一个常量，当它仅仅是当前没有改变时，这是提供错误信息。

一个问题是：什么类型的变量？

对于静态变量，在我所谓的“引导时间”之后不会改变，我使用ALL_CAPS...全局变量也是同样的情况（如果语言支持它们）...

命名约定实际上是传达语义的重点，看到ALL_CAPS清楚地说明了a）我不会写入它b）我可以缓存它（例如，本地变量或在AS3中甚至实例变量是有意义的，因为静态访问非常慢）...

它是否是“真正的常量”并不重要...那更多是一个实现细节，应该被隐藏起来（可靠！信息隐藏很好，很重要，但关键是共享的信息必须是可信的！）...它确实可以被替换...例如，我经常开始构建应用程序与一些硬编码配置相对比，其中包含一些静态常量...后来，我决定不想将其硬编码，而是从某个配置文件中获取，因此我加载它，并在引导过程中初始化所有伪常量...实际应用程序仍将它们视为常量，因为在引导后，这些值就是常量...我认为这是完全有效的...

在实例级别上，我不确定是否曾遇到过一种情况，可以非常确定某个字段永远不会改变…通常情况下，这会使类变得不灵活…

除此之外，通常可以声明只读属性，以获得编译时错误，这也是一个好方法…

就像其他任何事情一样 - 需要了解范围和上下文，才能知道某件事情是如何恒定的。因此 - 没有办法让每个人都满意。

遵循您所选择的语言使用的风格 - 80％的时间，这将足够清晰。另一种选择是高度过度思考的命名系统，为理想的技术正确性而牺牲生产力（即使您能够实现它，也很少有人真正欣赏它。）

创建一个包装类，其中只有一个私有静态字段。创建一个initField(..)和一个getField(..)静态方法。如果静态字段不为null，则initField会抛出/断言/否则错误。(对于原始类型，您可能需要使用原始类型和布尔值来跟踪初始化。)
在Java中，我更喜欢将这些类型的变量作为系统属性传递。然后，静态类可以执行以下操作：

public final int MY_INT = Integer.getInteger("a.property.name");

你也可以使用属性文件（参见java.util.Properties）来代替使用-D来指定它。这样你就可以得到：

public class Foo {

public static final int MY_INT;

static {
Properties p = new Properties();
try{
p.load( new FileInputStream("app.props"):
} catch(IOException e) {
//SWALLOW or RETHROW AS ERROR
}
MY_INT=Integer.parseInt( p.getProperty("my.int","17") ); //17 is default if you swallo IOException
}
...
}

我不确定在你选择的语言中是否合法，但在C++中，这将适用于你的目的：

#include <iostream>

int main()
{
    int i = 0;
    std::cin >> i;

    const int CONST = i; 
    std::cout << CONST; //displays i

    system("PAUSE"); 
    return 0;
}

我不确定这是否是道德的事情，但这确实解决了你的问题（除非你真的需要你的内存）。