C ++の変数、メソッドなどの良い命名規則は何ですか？
私はObjective-CとCocoaの世界から来ましたが、そこでは多くの慣習があり、多くの人はそれがあなたのコードを美しくすると言うでしょう！ C++でのプログラミングでは、このようなC++用の優れたドキュメントを見つけることができません。
標準C++には上記のようなものはおそらくないでしょうが、他のSDKまたはAPI（Microsoft（？）など）の慣習に固執できることを願っています。
いくつかのリンクを提供していただければ幸いです。
最小限で一貫性があり、かつ ルールに違反しない である限り、何でもできます。
個人的には、Boostスタイルが最も簡単だと感じています。これは標準ライブラリに一致し（コードに統一された外観を与える）、シンプルです。私は個人的に、それぞれmとpプレフィックスをメンバーとパラメーターに付け加え、以下を与えます：
#ifndef NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP
#define NAMESPACE_NAMES_THEN_PRIMARY_CLASS_OR_FUNCTION_THEN_HPP
#include <boost/headers/go/first>
#include <boost/in_alphabetical/order>
#include <then_standard_headers>
#include <in_alphabetical_order>
#include "then/any/detail/headers"
#include "in/alphabetical/order"
#include "then/any/remaining/headers/in"
// (you'll never guess)
#include "alphabetical/order/duh"
#define NAMESPACE_NAMES_THEN_MACRO_NAME(pMacroNames) ARE_ALL_CAPS
namespace lowercase_identifers
{
class separated_by_underscores
{
public:
void because_underscores_are() const
{
volatile int mostLikeSpaces = 0; // but local names are condensed
while (!mostLikeSpaces)
single_statements(); // don't need braces
for (size_t i = 0; i < 100; ++i)
{
but_multiple(i);
statements_do();
}
}
const complex_type& value() const
{
return mValue; // no conflict with value here
}
void value(const complex_type& pValue)
{
mValue = pValue ; // or here
}
protected:
// the more public it is, the more important it is,
// so order: public on top, then protected then private
template <typename Template, typename Parameters>
void are_upper_camel_case()
{
// gman was here
}
private:
complex_type mValue;
};
}
#endif
それ。 （コメントで言ったように、命名規則と同じくらい重要でないものを除いて、コードにGoogleスタイルガイドをnot採用します。）
おそらく、個人と同じ数の命名規則があり、どのブレーススタイルを使用するかなど、議論は無限（かつ不毛）です。
だから私は2つのアドバイスがあります：
- be consistentプロジェクト内
- 予約済みの識別子を使用しないでください（2つのアンダースコアを持つもの、またはアンダースコアで始まり、その後に大文字が続くもの）
後は君しだい。
実際によく使うのはJavaスタイル：型名にPascalCase、関数と変数にcamelCase、プリプロセッサマクロにCAPITAL_WORDSを使用します。 _type。例えば。
Size size();
の代わりに
size_type size(); // I don't like suffixes
これには、StackOverflowコードフォーマッタがSizeを型名として認識するという追加の利点があります;-)
このページにリストされているガイドラインに従います。 C++ Programming Style Guidelines
Misfeldt et alによるC++スタイルの要素 を読むこともお勧めします。これはこのトピックに関する非常に優れた本です。
C++の最初の作者であるBjarne Stroustrupには、ここで説明する独自のお気に入りのスタイルがあります。 http://www.stroustrup.com/bs_faq2.html
スタイルガイドのより広範な問題に対処するために、スタイルガイドを選んでそれに固執することをお勧めします。
Googleスタイルガイド は非常に詳細/包括的なため、適切な選択です。
命名の一般的な規則は次のとおりです。
camelCaseすべての名前（定数を除く）。- クラスの場合は大文字で始まります。
- そうでない場合は小文字。
- アンダースコア区切りの
ALL_CAPSの定数は機能します。 - 関数は変数
camelCaseと同じように書くことができます（後に()を必要とするため、関数であることがわかります）。 - そして、
mが前に付いたメンバー変数はmCamelCaseと記述されます。
それは本当にあなた次第です。あるいは、あなたが/のために働いている人々、またはあなたが勉強している大学次第です。
その背後にあるさまざまなスタイルガイド/理論的根拠の詳細については、Andrew HuntとDavid ThomasのPragmatic Programmerを参照してください。
多くの人が多かれ少なかれ厳格な提案をしますが ハンガリー語表記 バリアント（ 怖い ！）、命名の提案については Google C++コーディングをご覧になることをお勧めしますガイドライン 。これは最も一般的な命名規則ではないかもしれませんが、少なくともかなり完全です。健全な命名規則とは別に、そこにはいくつかの有用なガイドラインがありますが、その大部分は多少の注意を払う必要があります（例外の禁止、および現代のC++コーディングスタイルから遠ざかる傾向）。
個人的には、STLとBoostの極端なローテクコンベンションスタイルが好きですが;）。
一貫性と可読性（自己文書化コード）が重要です。衝突を回避し、インスタンスが必要かどうかを示すために、いくつかの手がかり（ケースなど）を使用できます。
私が始めたベストプラクティスの1つは、コードフォーマッタの使用でした（astyleとuncrustifyは2つの例です）。コードフォーマッタは、コードのフォーマットを破壊する可能性があります-フォーマッタを設定し、その機能を実行させます。真剣に、手動フォーマットを忘れて、それらを使用する練習に入ります。時間を大幅に節約できます。
前述のように、ネーミングは非常にわかりやすいものにしてください。また、スコープ（クラスの種類/データ/名前空間/匿名の名前空間）を非常に具体的にします。一般的に、私はJavaの一般的な記述形式の多くが本当に好きです。これは優れたリファレンスであり、c ++に似ています。
特定の外観/名前付けに関しては、これは私が使用するものに似た小さなサンプルです（変数/引数はlowerCamelであり、これは言語の機能の一部のみを示しています）：
/** MYC_BEGIN_FILE_ID::FD_Directory_nanotimer_FN_nanotimer_hpp_::MYC_BEGIN_FILE_DIR::Directory/nanotimer::MYC_BEGIN_FILE_FILE::nanotimer.hpp::Copyright... */
#ifndef FD_Directory_nanotimer_FN_nanotimer_hpp_
#define FD_Directory_nanotimer_FN_nanotimer_hpp_
/* typical commentary omitted -- comments detail notations/conventions. also, no defines/macros other than header guards */
namespace NamespaceName {
/* types prefixed with 't_' */
class t_nanotimer : public t_base_timer {
/* private types */
class t_thing {
/*...*/
};
public:
/* public types */
typedef uint64_t t_nanosecond;
/* factory initializers -- UpperCamel */
t_nanotimer* WithFloat(const float& arg);
/* public/protected class interface -- UpperCamel */
static float Uptime();
protected:
/* static class data -- UpperCamel -- accessors, if needed, use Get/Set prefix */
static const t_spoke Spoke;
public:
/* enums in interface are labeled as static class data */
enum { Granularity = 4 };
public:
/* construction/destruction -- always use proper initialization list */
explicit t_nanotimer(t_init);
explicit t_nanotimer(const float& arg);
virtual ~t_nanotimer();
/*
public and protected instance methods -- lowercaseCamel()
- booleans prefer is/has
- accessors use the form: getVariable() setVariable().
const-correctness is important
*/
const void* address() const;
virtual uint64_t hashCode() const;
protected:
/* interfaces/implementation of base pure virtuals (assume this was pure virtual in t_base_timer) */
virtual bool hasExpired() const;
private:
/* private methods and private static data */
void invalidate();
private:
/*
instance variables
- i tend to use underscore suffix, but d_ (for example) is another good alternative
- note redundancy in visibility
*/
t_thing ivar_;
private:
/* prohibited stuff */
explicit t_nanotimer();
explicit t_nanotimer(const int&);
};
} /* << NamespaceName */
/* i often add a multiple include else block here, preferring package-style inclusions */
#endif /* MYC_END_FILE::FD_Directory_nanotimer_FN_nanotimer_hpp_ */
C++をコーディングするときに人々が使用する多くの異なるスタイル/慣習があります。たとえば、大文字（myVarまたはMyVar）またはアンダースコア（my_var）を使用して単語を区切ることを好む人もいます。通常、アンダースコアを使用する変数はすべて小文字です（私の経験から）。
ハンガリー語と呼ばれるコーディングスタイルもあり、Microsoftが使用していると思います。個人的には時間の無駄だと思っていますが、役に立つかもしれません。これは、変数名にiやfなどの短いプレフィックスを付けて、変数のタイプを示すものです。例：int iVarname、char * strVarname。
構造体/クラス名を変数名と区別するために、_tで終了することが認められています。例えば。：
class cat_t {
...
};
cat_t myCat;
PVariableやvariable_pなどのポインタを示す接辞を追加することも一般的に受け入れられています。
全体として、実際には単一の標準ではなく、多数あります。変数に名前を付けることに関して選択することは、理解可能であり、とりわけ一貫性がある限り重要ではありません。一貫性、一貫性、一貫性！ （3回入力してみてください！）
そして、他のすべてが失敗した場合、それをグーグル。
本当に関係ありません。変数と関数にわかりやすい名前を付けてください。また、一貫している。
次のようなコードを見るよりも最悪です：
int anInt; // Great name for a variable there ...
int myVar = Func( anInt ); // And on this line a great name for a function and myVar
// lacks the consistency already, poorly, laid out!
編集：私のコメンターが指摘したように、チーム全体で一貫性を維持する必要があります。そのため、一貫性が維持されている限り、選択したWHATメソッドは重要ではありません。ただし、正しい方法や間違った方法はありません。私が働いていたすべてのチームは異なるアイデアを持っていて、それらに適応しました。
あなたが提供したリンクほどには簡潔ではありませんが、次の14〜24章が役立つかもしれません:) hehe