私はPythonおよびJavaで多くの作業を行っています。これらの言語はどちらも、識別子での大文字の使い方のかなり一般的な(普遍的ではありませんが)規則を持っています。どちらもPascalCase
を使用しますクラス名とALL_CAPS
は「グローバル」定数ですが、他の識別子では多くのJavaコードはmixedCase
を使用しますが、Pythonコードはunderscore_delimiters
を使用します。言語やライブラリはないことを知っていますenforces特定の大文字表記はありますが、言語の標準規則に固執すると、使用すると、私のコードははるかに読みやすくなります。
今はC++でプロジェクトを始めていますが、同じ考えを適用したいと思います。知っておくべき最も一般的な大文字の表記法はありますか?
知っておくべき最も一般的な大文字の表記法はありますか?
C++はCに基づいています。Cは、C++が発明されるまでに、多くの命名規則を開発するのに十分古いものです。その後、C++がいくつか追加しました。Cも新しいものを考えて遊んでいません。それに加えて、発明者のC命名規則をさらに発展させた多くのC派生言語が、CおよびC++に逆受精するまで...言い換えれば、C++には1つはありませんが、そのような慣習の多く。
ただし、1つの命名規則を探している場合は、標準ライブラリの命名規則これは、すべてのC++開発者が知って慣れなければならない単一の規則であるためです。
ただし、最も重要なルールを使用するものは次のとおりです:Be一貫性がある!
興味深いことに、私はPascalCaseとcamelCaseの混合から始め、さらに多くの命名規則を持つ多数のプロジェクトに携わっていましたが、長年にわたり、standard_library_conventionにだんだんとこだわっていました。理由を聞かないで。
すべての大文字は目障りであり、最小化する必要があることに最初に同意しましょう。
CとC++では、マクロは邪悪であるとは言えなく、醜いので、マクロとマクロのみの規約として使用されます。
初期のCにはconstがなかったため、定数はマクロとして表現する必要がありました。また、これらの初期の頃はプログラムがはるかに短かったため、今日は不適切なプラクティスを使用できました(たとえば、IIRCブライアンカーニガンは、大文字以外のマクロを多数含むコードを記述しました)。また、当時は小文字のないキーボードが存在していました。ノルウェーの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.
まあ、あなたは私が冗談で大文字のみのキーボードについて言及したと思ったかもしれません。大野。それは単に命名規則を推進する、または少なくともそれらがどのように間違っている/正しいと思われるかに影響を与えた最も古い、ほとんどの古くからあるテクノロジーの制限であるためです。次に、7ビットのシリアル伝送の問題があり、使用された文字コード(newspeak文字エンコード)に対応する問題が発生したため、英語のアルファベット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つの連続するアンダースコアを含む、またはアンダースコアで始まり、グローバル名前空間にあるような予約名の使用は避けてください。
乾杯&hth
私は通常、言語の既存のコードベースで最もよく見られる慣習に固執する傾向があります。 C++の場合、通常はcamelCaseが表示されます。 RubyまたはPHPの場合、私は通常stuff_like_thisを参照します。
ただし、現実的に言えば、最も重要なことは、完全に正気ではないスタイルの規則(dOnT_dO_tHiS)を選択し、それと一貫していることです。特定のプロジェクトのコード全体でスタイルが変更されないようにします。既存のプロジェクトで作業している場合は、既にあるスタイルを使用することをお勧めします。
Systems Hungarian がありますが、これは今でも本当に一般的ですが、推奨するよりも自分の喉を切りたいと思っています。 Apps Hungarianは、その異例のマークが本当に意味論を示しているので優れていますが、短いWordの場合は略語にあまりにも熱心すぎると思います。 (そのWikipediaページの例を使用するには、rw
が1文字だけ長いのに、なぜrow
を行に使用するのですか?それは、全体的な母音の不足があるようなものではありません。)
現実的には、最も重要なことは、作業している人々の慣習に従うことです。本当に。ほとんどの規則は、特に一貫して使用されている場合は、十分に機能します。矛盾は最悪です(私が嫌うSystems Hungarianよりもなおさらです)。そして、あなたが独りでいるならば、あなたが好きなものを使ってください。
私が見たものから、それはプロジェクト間で異なります。
埋め込まれたアンダースコアは、おそらくより伝統的/ Unix上のCでより一般的に使用されています。標準ライブラリもこれに準拠しているため、shouldはほぼ確実にデフォルトとして扱われ、他の規則を使用する既存のコードが他の規則を絶対的に強制するのに十分でない限り、使用されます。
Windows(一例として)は、その機能のほとんどにキャメルケースを使用しているため、Windows用に開発するかなりの人が同じことをしています。これは、他の言語に本当に慣れていて、C++を他の何かの奇妙な変種であるかのように扱うことを試みる人々の間でもかなり一般的です。
命名規則の参照として、標準ライブラリとブーストの両方を使用しました。ただし、このソリューションには問題があります。
標準ライブラリは、コードとの衝突を減らすために設計された命名規則を使用しています。解決策の一部は、すべて小文字を使用することです。したがって、キャメルケースの代わりにアンダースコアを使用します。
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