C ++に一般的な大文字表記規則はありますか？[閉まっている]

私はPythonとJavaで多くの仕事をしており、両方の言語には識別子で大文字を使用する方法に関するかなり一般的な（普遍的ではない）規則があります：PascalCaseクラス名とALL_CAPS「グローバル」定数の両方で使用しますが、他の識別子には多くのJavaコードが使用するのmixedCaseに対し、多くのPythonコードはを使用しunderscore_delimitersます。特定の大文字と小文字を強制する言語やライブラリはないことは知っていますが、使用している言語の標準的な規則に従うと、コードがはるかに読みやすくなることがわかりました。

今、私はC ++でプロジェクトを開始していますが、同じアイデアを適用したいと思います。大文字と小文字の区別について知っておくべき最も一般的な規則はありますか？

大文字と小文字の区別について知っておくべき最も一般的な規則はありますか？

C ++はCに基づいています。Cは、C ++が発明されるまでに多くの命名規則を開発してきたほど古いものです。その後、C ++がいくつか追加されましたが、Cも新しいものを考えていませんでした。さらに、発明者のC命名規則をさらに発展させた多くのC派生言語が、CおよびC ++に逆受精するところまで追加されます。つまり、C ++には1つではなく、そのような多くの規則があります。

ただし、1つの命名規則を探している場合は、標準ライブラリの命名規則も参照してください。これは、すべてのC ++開発者が知って慣れなければならない単一の規則です。

ただし、最も重要なルールを使用すると、一貫性が保たれます。

興味深いことに、私はPascalCaseとcamelCaseの混合から始めて、さらに多くの命名規則を持つ多数のプロジェクトに関与していましたが、長年にわたって、standard_library_conventionにますますこだわってきました。理由を聞かないでください。

最初に、すべての大文字は目障りであり、最小化する必要があることに同意しましょう。

したがって、CとC ++では、マクロは悪とは言わないまでも同様にいため、マクロとマクロのみの規則として使用されます。

初期のCにはconstがなかったため、定数はマクロとして表現する必要がありました。また、これらの初期のプログラムは非常に短いため、今日では不適切なプラクティスを使用できます（たとえば、IIRC Brian Kernighanは、大文字以外のマクロを多く使用してコードを記述しました）。また、当時は小文字のないキーボードが存在していました。ノルウェーのTandberg EC-10コンピューターで1980年または1979年頃に使ったようなものを使用しました。

そのため、Javaは初期Cの定数の大文字の規則を採用しました。その間、おそらくその前（おそらく、ここでの年表はわかりません）、Cは定数を取得しました。ただし、当然のことながら、一部の/多くのCプログラマーは大文字のマクロとして定数の必要性により以前の慣習にとらわれていましたが、C ++プログラマーはより賢明でした。

最近の大きな問題は、人々が最初にJavaを、またはC（中世からの慣習）を最初に教えられ、次にC ++に来て、その不正な大文字の慣習を採用することです。

そう、

    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

あなたは私がjestで大文字のみのキーボードに言及したと思ったかもしれません。大野。それは単に命名規則を推進した、または少なくともそれらが間違っている/正しいと思われる方法に影響を与えた、最も古く、最も古い技術の制限であるためです。次に、7ビットシリアル伝送の問題があり、使用された文字コード（ニュースピーク文字エンコード）に対応する問題が発生しました。つまり、英語のアルファベットA〜Zの文字に制限する必要がありました。

実際、私はまだそれを行うことをお勧めします。それが私たちがいるところです！これ以上はありません。

現時点では、2011年の時点で、標準C ++は名前で一般的なUnicodeをサポートしていますが（実際には1998年からサポートしています）、実際のC ++実装はサポートしていません。特に、g ++コンパイラーは各国のキャラクターに挑戦しています。それは、暗黒時代の技術的制限に起因します。

そう、

    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

最後に、アンダースコアと大文字が散在していることに関しては、

• 型名に簡単に認識できるフォームを予約します。
• マクロのすべての大文字を予約します。
• 一貫してください。

「（loop、template param、blah blah）を除く一般的に1文字の名前を避ける」、「lの使用を避け、1と混同しやすい」、「大文字のOを避ける、混同しやすい」などのルールを除いて、本当にそうだと思います0 "で。また、もちろん、アンダースコアで始まり、大文字が続く、2つの連続するアンダースコアを含む、またはアンダースコアで始まりグローバル名前空間にあるような予約名の使用は避けてください。

乾杯

私は通常、その言語の既存のコードベースで最もよく見られる慣習に固執する傾向があります。C ++の場合、通常はcamelCaseが表示されます。RubyまたはPHPの場合、通常stuff_like_thisが表示されます。

ただし、現実的に言えば、最も重要なことは、完全に正気でない（dOnT_dO_tHiS）スタイル規則を選択し、それに従うことです。特定のプロジェクトのコード全体でスタイルが変わらないようにします。既存のプロジェクトで作業している場合は、すでにそこにあるスタイルを使用する必要があります。

さて、System Hungarianは今でも一般的ですが、推奨するよりも自分の喉を切りたいです。Apps Hungarianは、その注釈マークがセマンティクスを本当に示しているため、より優れていますが、短い単語があれば略語にはやや熱心すぎると感じています。（そのウィキペディアのページの例を使用するrwために、なぜrow1文字だけ長い場合に行に使用するのですか？グローバルな母音不足があるようではありません。）

現実的には、最も重要なことは、あなたが働いている人々の慣習に従うことです。本当に。特に一貫して使用される場合、ほとんどの規則は十分に機能します。矛盾は最悪です（私が嫌いであるシステムハンガリー語よりもさらに）。そして、あなたが一人でいるなら、あなたが望むものを使ってください。

私が見たものから、それはプロジェクトによって異なります。

埋め込みアンダースコアは、おそらくより伝統的であり、UnixのCではより一般的に使用されます。ので、標準ライブラリは、同様にこれを次の必要があり、ほぼ確実に絶対に他の規則を使用して強制的に別の規則を使用して十分な既存のコードがありますしない限り、使用される、デフォルトとして扱われます。

Windows（ほとんどの場合）は、ほとんどの機能にキャメルケースを使用しているため、Windows用に開発する人の多くは同じことをしています。これは、他の言語に実際に慣れている人々の間でもかなり一般的であり、C ++を他の言語の単なる変種であるかのように扱うことを試みます。

命名規則の参照として、標準ライブラリとブーストの両方を使用しました。ただし、このソリューションには問題があります。

標準ライブラリは、コードとの衝突を減らすために設計された命名規則を使用します。解決策の一部は、すべて小文字を使用することです。したがって、camelCaseの代わりにアンダースコアを使用します。

camelCaseが読みやすいことがわかりました。PascalCaseは、適切な名詞に相当するため、クラス名によく使用されます。ただし、動詞をより代表するファンクターについては、この規則を破ります。

マクロを使用しないようにします。しかし、そうすると、マクロはできる限り関数のように見えます。また、マニフェスト定数の代わりにconst値または列挙を使用し、さらにすべての大文字を回避します。通常、これらのシンボルの先頭に「k」を付けて、それらが一定であることを示します。

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60
};

このリファレンスでは、過去に勤務した少なくとも3社で成功して使用されているのとよく似た命名規則について説明します。

以前の回答とは反対に、標準ライブラリとの名前の衝突を回避する以外の理由がない限り、自分のコードでC ++標準ライブラリの命名規則に従うことは避けます。

関連するトピックに関するこの以前のSOの回答も興味深いかもしれません：https : //stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-ac-identifier