C++コードスタイルの思考

C++/Cは彼がバイナリ基準を持っていないように、統一的なコードスタイルがなく、unixスタイルがあり、ハンガリースタイルがあります.自分が長い間憂鬱だったが、google C++styleのドキュメントを見て利益を得た.しかし、STL、MS、Qtなどのコードスタイルはそれぞれ異なり、個人的にはいくつかの思考が生まれた.
インデント
tabですか、スペースですか.より多くのドキュメントでは、tabを使わずにスペースを使うことをお勧めしますが、tabのメリットは依然としていくつかあります.Linuxコードにはtabが必要で、幅は8つのスペースです.
2、4、8個のスペース?これは異なるインデント深さに対応していますが、2つのスペースは明らかではありませんか?8つのスペースは手が痛いのではないでしょうか.4つのスペースのほうがいいようですが、マルチレベルのインデントが2つのスペースよりも早く80文字以上の境界を超えます.
かっこ
かっこ(または他の演算子)は行の最後に続くのか、それとも別の行に続くのか.行末に置いて次の行に内容があることを知っていて、次の行に置いた理由はあなたがいないのです";"この行はきっと完成していないで、更に単独の行が前の行から続くことを知っています.
変数と名前付け
クラス変数は前ですか、それとも関数は前ですか.
ハンガリーの名前ですか、アルパカですか、それとも全小文字の下線分割ですか.STLとunix系のマスターたちは下線分割で、ハンガリーはMFCの寵愛のようだが、アルパカはQtでjava、C#などの言語で多く使われている.のスタイルです.
メンバー変数がどのように定義されるか、mを追加するかmを追加するか、接尾辞を追加するか、または修飾を追加しないか変数の前にタイプIDを付ける必要はありますか?元のタイプのデータを使用している場合、変数のタイプを効率的に区別するようですが、多くのタイプをカスタマイズしているので、このルールはそんなに使いにくいようですか?
ヘッダファイル定義順序
まずヘッダファイルをカスタマイズした後、システムヘッダファイルは、カスタムファイル内の競合をより迅速に発見することができます.
システムヘッダファイルの後にファイルをカスタマイズし、ヘッダファイルの依存性を低減します.
コメント
注釈の第一の目的は、コードを見ている人にコードの意味を迅速に理解させることであり、開発ドキュメントを生成することができる機能もある.doxygenは、ドキュメントを生成するための比較的一般的なより注釈生成ツールであり、オープンソース境界はこのようなスタイルの注釈に傾いている.
ファイル
1つのファイル1つのクラスですか、それとも機能別にファイルを分けますか.
ファイルの最後に空白行が1つ増えましたか?これは何の害もないようだ.
まとめ
そのスタイルにかかわらず、1つのプロジェクトで統一されるべきで、あなたの好悪にかかわらずどんなスタイルの注釈私はいわゆる、肝心なあなたは注釈を持って事をはっきり言うべきですどんなスタイルでも、あなたのコードはきっと美しくきれいなです.
コードスタイルのすべては効率のバランスのためです