用大写字母命名常量的惯例背后的历史是什么？

我的直觉是从C预处理程序开始的，在C预处理程序中，人们开发了一种做法，以所有大写形式命名预处理程序宏，以便它们可以有效地存在于单独的命名空间中，并避免名称冲突。我的信念是，这种做法后来被误解并混为一谈，也适用于非预处理程序常量（enums，const变量）。

在所有大写字母中命名预处理器宏对我来说确实有用。用这种方式命名通用常量不是那么多（如果它与宏名称产生冲突，则会适得其反）。

我在基地外吗？大写常量的惯例是否早于C？

对于C，第一版的C编程语言（又名K＆R）表明您对预处理器宏的直觉是正确的：

符号常量名通常以大写形式编写，因此可以轻松将它们与小写变量名区分开。

在许多方面，这是汇编语言的遗留问题，在汇编语言中，宏与标签，操作码，寄存器名称以及其他所有内容一起以大写形式定义。AT＆T样式的装配的出现改变了某些平台上的装配，但是我认为这很大程度上受到以下事实的影响：支持小写字母的终端已成为一种事物，而Unix被我称为“小写字母操作系统”。

在其他两点上，您的目标是.500：

枚举

到第二版出版时，enum已经定义了，它们被称为枚举常量，并在常量部分中进行了介绍。因为由定义的常量enum用符号表示，所以使它们成为符号常量，如果要遵循建议的约定，则应使用大写字母命名。（就像预处理器宏一样，没有任何事情可以阻止您执行其他操作。）

这里的含义是，与后面的某些语言不同，C不会将enum其本身视为不同的第一类类型，枚举值特定于每种类型，并且可以在其他类型中重复使用。取而代之的是，它实际上是一个便捷的简写形式，#define可以生成带有标识符的整数序列。这使得

enum foo  { BAR, BAZ };
enum quux { BLETCH, BAZ };

无效，因为所有符号都共享作用域并BAZ已重新定义。（这是对预处理器的改进，当时预处理器没有警告过会#define破坏另一个。）此外，C不在乎是否混合它们，因为它们都是整数，因此

enum foo  { BAR, BAZ };
enum quux { BLETCH, BLRFL };

enum foo variable = BLETCH;

甚至在打开所有警告的现代编译器上也完全有效。

康斯特

注意：该const关键字起源于1981年，是Stroustrup的C With Classes（演变为C ++），最终被C所采用。名称的选择很不幸，因为它与K＆R使用常量一词相冲突，即我们现在称之为“ 常数”。文字（例如38，'x'或"squabble"）。第二版中的文字并未经过重写以反映这一点。

声明const的变量是另一回事，因为它们仍然是变量。他们不应该被修改，但是常量变量的概念是否比巨型虾更有意义？不管是哪种情况，C都从来没有真正认真对待过它，因为该标准仅要求编译器在尝试更改诊断时发出诊断信息。如果编译并执行修改，则实际行为是不确定的。

作为变量，任何事物const都应遵循小写命名的惯例。使用它们来表示文字确实具有一些类型安全性优势，但是如果您必须在编译单元之间获取值，就不能进行良好的优化。

从K＆R角度来看，它们不是常量，因此，其标识符不应为大写。有些人以这种方式使用它们，但除少数特定情况外，我不建议您这样做。