我知道对于C++和Java来说，有一个被广泛接受的命名规范，即常量应该全部大写，用下划线分隔单词。比如这样（Java示例）：
public final static Color BACKGROUND_COLOR = Color.WHITE;
public final static Color TEXT_COLOR = Color.BLACK;
这种命名约定易于理解和遵循，但我问自己，为什么选择这种命名约定而不是普通的变量命名约定：
public final static Color backgroundColor = COLOR.WHITE;
public final static Color textColor = COLOR.BLACK;
似乎没有必要改变常量的外观。如果我们想给它们分配一个值，编译器会阻止这样做。事实上，如果以后将常量更改为适当的变量（例如，因为颜色变得可配置），则会出现问题。
那么为什么要将命名常量全部大写呢？是出于历史原因吗？
我认为这不是一个技术问题，而是一个心理问题。命名约定不是供编译器处理的（计算机实际上并不介意名称），而是为了使浏览代码的程序员尽可能获得更多信息，尽可能少的付出努力。
使用不同的命名约定明显告诉读者，你正在阅读的是在编译时被固定的东西，你不需要沿着代码跟踪确定值是如何到达那里的。
我认为在C++中，这是一种从使用预处理器定义常量值的日子延续下来的惯例。当时这样做是为了避免预处理器践踏源代码，因为C函数和变量名通常是混合大小写或小写。
从C++的角度来看，我会说把所有常量都大写是个坏主意。我曾经因此调试过多个构建问题 - 记住，C++预处理器对命名空间和名称范围一无所知，并且会很愉快地替换它认为适当的东西，尽管它是相当不恰当的。
kConstantName 的原因。一个在某种程度上保留旧风格的替代方案是 k_CONSTANT_NAME。 - Emile Cormier我可以想象在 C 语言的早期，人们会使用预处理器来以符号方式实现"常量":
typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff
这样的“常量”只是装饰过的文字，因此它们的行为与变量并不完全相同。例如，您无法获取此类“常量”的地址：
Color *p = &BACKGROUND_COLOR; // Breaks!
因此，让它们“突出显示”是有意义的，因为它们真的不仅仅是“无法更改的变量”。
如果我知道某个东西是一个常量，我可以多次引用它并且知道它不会改变。换句话说，我知道：
Color black = Colors.BLACK;
foo(black);
foo(black);
与以下代码等效：
foo(Colors.BLACK);
foo(Colors.BLACK);
有时候了解这点信息会很有用。就我个人而言，我更喜欢使用.NET的命名约定，即对于常量（和方法）使用Pascal case：
Foo(Colors.Black);
Foo(Colors.Black);
我不是很喜欢大声的命名方式...但我确实喜欢常量显然是常量。
#define定义的符号都是大写的，这是向开发人员发出的响亮信号，表明代码并不像看起来那样，并且不能将其视为正常符号。在K&R C中最初不存在常量（尽管后来从C++中引入了const），因此开发人员使用#define代替，因此采用了大写字母的方式。我认为大写常量是从C语言遗留下来的不好习惯。其背后的逻辑与在私有成员前使用下划线前缀相同。这些都是技术性的细节，已经通过Java关键字（如private）或常量的情况下static final表达出来了。
我个人认为全大写字母存在的原因是，在非常老的机器上，使用数字键盘直接输入机器码。当汇编语言出现时，它只使用全大写字母，因为当时的键盘没有标准化，有些键盘受限，例如将相同的数字键盘用于像功能手机那样输入字母。这被延续到许多早期的语言中，如BASIC，其中一切都是大写字母。当实际终端可用并且键盘开始标准化时，人们开始使用混合大小写字母而没有保留全大写字母用于某些不太常见的情况，例如与函数和变量相比常量。
现在大多数C ++指南都同意使用“k”作为常量前缀，后跟下划线或CamelCase命名。我个人更喜欢kCameCase，因为它可以轻松区分变量，这些变量使用下划线命名。
const float kFixedRadius = 3.141;
基本上，早在人们热爱C语言时，C ++和Java要么是新的，要么尚未创建，人们使用全部大写字母来表示预处理器常量名称，以表明它们实际上并不是变量。
#define INT_CONST 4
#define STRING_CONST "Yello."
#define FLOAT_CONST 3.6122448
使用大写常量可以使长公式更易读，您不需要猜测哪个元素可以变化，哪个元素不能变化。这当然只是一种惯例，但是非常有帮助。