命名：C ++ / Javaで名前付き定数をすべて大文字にする必要があるのはなぜですか？
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;
定数の見た目を変える必要はないようです。それらに値を割り当てたい場合、コンパイラはこれをとにかく防ぎます。後で定数が適切な変数に変更されると、実際に問題が発生します（たとえば、色が構成可能になるためです）。
では、名前付き定数をすべて大文字で書く究極の理由は何でしょうか。歴史的な理由は？
技術的な問題ではなく、心理的な問題だと思います。命名規則は、コンパイラーが処理する（コンピューターは実際には名前を気にしない）ためのものではなく、コードを参照しているプログラマーが必要最小限の労力でできるだけ多くの情報を取得するためのものです。
別の命名規則を使用すると、読んでいるものはコンパイル時に修正されたものであり、コードをたどってどこにどのように値が到達したかを判断する必要がないことを読者に明確に伝えます。
何かが定数であることを知っている場合、それを何度も参照して、変更されないことを知ることができます。言い換えれば、私はそれを知っています：
Color black = Colors.BLACK;
foo(black);
foo(black);
と同じです：
foo(Colors.BLACK);
foo(Colors.BLACK);
それは時々知っておくと役に立ちます。個人的には、定数（およびメソッド）にPascalの大文字小文字を使用する.NET命名規則を好みます。
Foo(Colors.Black);
Foo(Colors.Black);
私はシャウトケースの大ファンではありません...しかし、定数が明らかに定数であるのが好きです。
最初はC時代に、人々はプリプロセッサを使用して「定数」を象徴的に実装したと想像できます。
typedef unsigned int Color;
#define BACKGROUND_COLOR 0xffffff
このような「定数」は単なるリテラルであり、そのため、変数としては完全には機能しません。たとえば、そのような「定数」のアドレスを取ることはできません。
Color *p = &BACKGROUND_COLOR; // Breaks!
このため、「変更できない変数」ではないので、「目立つ」ようにするのが理にかなっています。
C++では、プリプロセッサを使用して定数値を#defineする時代から引き継がれた慣習だと思います。当時は、C関数と変数名の通常の規則では大文字と小文字が混在したり小文字になったりするため、ソースコード全体でプリプロセッサが踏みにじられないようにするために行われました。
C++の観点からは、定数をすべて大文字にするのは悪い考えだと思います。このため、1つ以上のビルド問題をデバッグする必要がありました。C++プリプロセッサーは名前空間とネーミングスコープについて何も知らないため、不適切であるとしても、適切だと思われるものを喜んで置き換えます。
定数がマクロであったという理由だけで、定数にALL_CAPSを使用しないでください。
これは、C++コアガイドラインの quote ですべてまとめられています。
Cでは（そしてC++では）、プリプロセッサ#defineディレクティブで定義されたシンボルは、コードが見た目ではなく、通常のシンボルとして扱われないことを、開発者に大きな信号としてすべて大文字で書かれていました。定数は当初K＆R Cには存在しませんでした（ただし、constは後でC++から持ち帰られました）ので、開発者は代わりに#defineを使用しました。
何らかの理由で、これはJava "定数はキャップ"であるため、現在の誤った（IMO）規約になっています）.
大文字の定数はCの悪い遺産だと思います。背後にあるロジックは、プライベートメンバーのプレフィックスとしてアンダースコアを使用する場合と同じです。これは、Java privateのようなキーワード、または定数の場合はstatic final。
大文字の定数を使用すると、長い式の方がはるかに読みやすくなり、どの要素が変化し、どれが変化しないかを推測する必要はありません。もちろんこれは単なる慣例ですが、役立つものです。
これは、開発ツールが便利な方法で識別子のプロパティを見つけることができない場合の回避策です。
ハンガリー語の表記によく似ています。
IDEが良くなれば、命名規則は必要ありませんが、名前が識別子の意味に関する包括的な情報であることを示すものは必要です。
それでも進化する可能性があります：識別子を作成するだけのプログラミングシステムを作成し、それに「簡単な説明」、「タイプ」などのプロパティを追加してみませんか。便利な方法でこれを行うことができるツールが到着したら、私はm in。 " Intentional Programming "はヒントです。
基本的に、人々がCに夢中になっていて、C++＆Javaが新しいかまだ作成されていない場合、人々はプリプロセッサの定数名にすべて大文字を使用し、実際には変数ではなかったことを示しました。
#define INT_CONST 4
#define STRING_CONST "Yello."
#define FLOAT_CONST 3.6122448
これがCで真の定数を定義する唯一の実際の方法であることを考えると（方法がわかっていればconst変数を変更することも可能です）、そのようなプリプロセッサ定数は定数として見なされ、その意味はすべて大文字の名前は、一般にプリプロセッサ定数から単なる定数にシフトしました。これはその後、後の言語にも引き継がれ、標準的な「制約=資本」の慣行になります。
ただし、他の言語には独自の優先スタイルがあります（たとえば、C＃および.NETはPascalCaseを優先します）。
おそらくあなたは正しいです。コンピューターとコンパイラー（特に）は、今日ほど高速ではありませんでした。
Joel Spolskyは 彼のエッセイの1つ で言及しました。彼はTurbo Pascalの新しいバージョンのコンパイル時間にどれほど感銘を受けましたか。
PC上のTurbo Pascal 5.0でオーバーレイを使用した、それほど大きくないプログラム（10-20KLOC）のコンパイルは、XT= 10MHzで約20分かかりました...
エラーを検出するためのコンパイルの待機は受け入れられなかったと思います。
そして、そのような慣習は、壊れたコンパイル中のエラーや無駄な時間を避けるのに役立ちます。
プログラミングするときは、人間が理解できるコードを作成することが重要です。これには、命名規則があると役立ちます。これは、自分で記述していないコードを見る場合に最適です。定数や変数と簡単に区別できるため、コードの保守性が向上します。
実際、ほとんどのC++命名ガイドライン（ISO、Boost、Sutter＆Stroustrup、Googleを含む）では、すべての大文字で定数を命名しないことを強くお勧めしています。これは、マクロでもすべて大文字が使用されており、ヘッダーファイル内に散らばっている可能性があり、奇妙な動作を引き起こす可能性があるためです。人々は古いC/K＆Rまたは古いレガシーコードから学ぶため、とにかくすべて大文字を使用します。ただし、Modern C++の新しいコードでは、マクロ以外のすべてにすべて大文字を使用することは避けてください。
すべての大文字がまったく存在する理由についての私の理論では、非常に古いマシンでは、テンキーを使用してコードがマシンコードに直接入力されていました。アセンブリ言語が登場したとき、当時のキーボードは標準化されておらず、一部のキーボードが制限されていたため、すべての大文字しか使用されていませんでした。たとえば、フィーチャーフォンのように同じテンキーを使用してアルファベットを入力できます。これは、BASICのような多くの初期の言語に引き継がれ、すべてがすべて大文字になっています。実際の端末が利用可能になり、キーボードが標準化され始めたとき、人々は予約なしで混合ケースを使用し始め、すべての大文字は関数や変数に比べて定数のようなまれなもののために予約されました。
ほとんどのC++ガイドラインでは、定数の接頭辞として「k」を使用し、その後にアンダースコアまたはキャメルケースの名前を付けることに同意しています。私は個人的にkCameCaseを好みます。これは、under_scoresで名前が付けられた変数と簡単に区別できるためです。
const float kFixedRadius = 3.141;
これは純粋にプログラマーが一目で何を見ているかを理解するのを助けるためです。定数が使用されていることを知るのに役立ち、どのように参照しても値が変化しないようにします。それ。
コンパイラー側のことに関しては、実際には理由はありません。命名規則は純粋にそれであり、実際の技術的な制限ではありません。
コーディング変換は読みやすさを向上させるためのものです。文字を使用する必要はありません。 Javaは、たとえば$記号を許可します。
public final static Color $$ = COLOR.WHITE;
public final static Color $_ = COLOR.BLACK;
変数に番号を付けることもできますが、それは良い考えではありません。 ;）