すべて大文字の定数の命名規則の背後にある歴史は何ですか？

私の直感では、Cプリプロセッサから始めました。人々は、プリプロセッサマクロをすべて大文字で命名するプラクティスを開発しました。私の信念は、この慣行はその後誤解され、非プリプロセッサ定数（enums、const変数）にも適用されるように野放しにされたというものです。

プリプロセッサマクロにすべて大文字の名前を付けると、本当に便利に思えます。一般的な定数の命名は、それほどではありません（マクロ名と衝突する場合は逆効果です）。

私は基地を離れていますか？定数を大文字にする慣行はCよりも前でしたか？

Cの場合、Cプログラミング言語（別名K＆R）の初版では、プリプロセッサマクロに関する直感が正しいことを示唆しています。

記号定数名は一般に大文字で記述されるため、小文字の変数名と簡単に区別できます。

これは、多くの点で、マクロが大文字でラベル、オペコード、レジスタ名などすべてと一緒に定義されたアセンブリ言語からの持ち越しでした。AT＆Tスタイルのアセンブリの出現は、一部のプラットフォームでそれを変えましたが、小文字をサポートする端末がものになり、Unixが「小文字オペレーティングシステム」と呼ばれるものになったという事実に大きな影響を受けたと思います。

他の2つのポイントでは、.500を打つことになります。

列挙型

第2版​​が発行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;

すべての警告がオンになっている最新のコンパイラでも完全に有効です。

定数

NB：constキーワードは（C ++に進化し）クラスとStroustrup氏のCで1981年に生まれ、最終的にそれが長期のK＆Rの使用と衝突するので、名前の選択は、不幸であるC.で採択された定数我々は今呼ぶものを意味しますリテラル（例えば、38、'x'または"squabble"）。第2版​​のテキストは、それを反映するように書き直されていません。

宣言さconstれた変数は、まだ変数なので、別の話です。それらは修正されることは想定されていませんが、たとえばジャンボシュリンプよりも定数変数の概念が意味をなすかどうかは、別の議論の餌食になります。いずれにせよ、Cはそれを変更しようとしたときにコンパイラが診断を発行することだけを標準で要求しているので、Cについて決して真剣ではありませんでした。変更がコンパイルおよび実行される場合、実際の動作は未定義です。

変数であるため、何でもconst小文字で命名されるという慣習に従うのは理にかなっています。これらを使用してリテラルを表現することには、型安全性の利点がいくつかありますが、値を取得するためにコンパイル単位間を移動する必要がある場合は、最適な最適化にはなりません。

それらはK＆Rの意味で定数であり、そのため、識別子は大文字であってはなりません。一部の人々はそれらをそのように使用しますが、いくつかの特定の場合を除いて、それは私が推奨する習慣ではありません。