メンバー変数にはどのような接頭辞を使用しますか?

Question

間違いなく、メンバー変数を「通常の」変数と簡単に区別できるように、メンバー変数にプレフィックスを付けることがコードを理解するために不可欠です。

しかし、どのようなプレフィックスを使用しますか?

私はこれを使用したプロジェクトに取り組んできました。 m_ 他のプロジェクトでは接頭辞としてアンダースコアのみを使用しました (アンダースコアのみでは十分に説明できないため、個人的には好きではありません)。

別のプロジェクトでは、変数の型も含む長いプレフィックス形式を使用しました。 マル_ たとえば、 の接頭辞です。 メートルタイプのember変数 あなた署名済み 私オン。

では、どのような種類のプレフィックスを使用しているのか教えてください (その理由も教えてください)。

編集： ほとんどの人は、メンバー変数に特別な接頭辞を付けずにコーディングしているようです。これは言語に依存しますか?私の経験から言えば、 C++ コード アンダースコアを使用する傾向があるか、 m_ メンバー変数の接頭辞として使用します。他の言語についてはどうですか?

Answer 1

間違いなく、メンバー変数を「通常の」変数と簡単に区別できるように、メンバー変数にプレフィックスを付けることがコードを理解するために不可欠です。

私はこの主張に異議を唱えます。中途半端な構文強調表示がある場合は、これはまったく必要ありません。優れた IDE を使用すると、読みやすい英語でコードを記述でき、シンボルの型と範囲を別の方法で表示できます。Eclipse は、挿入ポイントがシンボルのいずれかにあるときに、シンボルの宣言と使用を強調表示するという優れた機能を備えています。

編集、ありがとうスリム:Eclipse のような優れた構文ハイライトを使用すると、太字または斜体のテキストを使用したり、フォントを完全に変更したりすることもできます。たとえば、私は静的なものを斜体にするのが好きです。

別の編集:このように考えてください。変数の型とスコープは二次情報です。それは利用可能で簡単に見つけられるべきですが、大声で叫ぶ必要はありません。次のような接頭辞を使用する場合 m_ または次のようなタイプ LPCSTR, 、コードの意図という一次情報を読みたいだけの場合、それはノイズになります。

3回目の編集:これは言語に関係なく当てはまります。

Answer 2

プレフィックスは一切使用しません。ローカル変数またはメソッド パラメータとクラス メンバーを混同する危険がある場合は、 その場合、メソッドまたはクラスのいずれかが長すぎるため、分割する方が有利です。.

これにより、(おそらく) コードが読みやすくなり、ある程度「流暢」になるだけでなく、最も重要なことは、 適切に構造化されたクラスとメソッドを奨励します. 。したがって、最終的には、接頭辞または接頭辞なしのジレンマとはまったく異なる問題に帰着します。

アップデート：まあ、味や好みは変わりますね。長期的にはローカル変数とメンバー変数を認識するのに有益であることが証明されているため、現在はメンバー変数の接頭辞としてアンダースコアを使用しています。特に新しいチームメンバーは、この 2 つが簡単に認識できないと苦労することがあります。

Answer 3

なし。私は以前はアンダースコアを使用していましたが、他のプロジェクトがそれを好まないプロジェクトでアンダースコアを使用しないように話されましたが、それを見逃したことはありません。まともな IDE やまともなメモリがあれば、何がメンバー変数で何がそうでないかがわかります。私たちのプロジェクトの開発者の一人は、「これ」を置くことを主張しています。すべてのメンバー変数の前で、私たちは名目上「彼」のコード領域に取り組んでいるときに彼をユーモアします。

Answer 4

アンダースコアのみ。

私の場合、職場のコーディング標準文書にそのように記載されているため、これを使用しています。ただし、変数の先頭に m_ などの恐ろしいハンガリー語を追加する意味がわかりません。最小限の「アンダースコアのみ」により、読みやすくなっています。

Answer 5

一貫性を保つことが何よりも重要なので、あなたとチームメイトが同意できるものを選択し、それを守り続けてください。また、コーディングしている言語に規則がある場合は、それに従うように努める必要があります。一貫性のない接頭辞規則に従っているコード ベースほど混乱を招くものはありません。

C++ の場合、_ がコンパイラ キーワードの前に付けられる場合があるという事実のほかに、_ よりも m_ を優先するもう 1 つの理由があります。m はメンバー変数を表します。これにより、ローカル変数と変数の他のクラス (静的の場合は s_、グローバルの場合は g_) との間の曖昧さを解消することもできます (ただし、もちろんグローバルは使用しません)。

IDE が常に面倒を見てくれるというコメントに関しては、本当に IDE がコードを確認する唯一の方法なのでしょうか?あなたの diff ツールは、IDE と同じレベルの構文強調表示の品質を備えていますか?ソース管理リビジョン履歴ツールについてはどうですか?ソースファイルをコマンドラインにcatすることさえないのですか？最新の IDE は素晴らしい効率化ツールですが、コードを読むコンテキストに関係なく、コードは読みやすくなければなりません。

Answer 6

私は使用することを好みます this キーワード。つまり、 this.data または this->data コミュニティに依存した名前の代わりに。

なぜなら：

• 最近の IDE の入力では this. ポップアップインテリセンス
• 定義された名前を知らなくても誰にとっても明らかです

ところで、変数の型を示す文字を変数の前に付けるのは、優れた IDE では時代遅れであり、これを思い出させます。 ジョエルさんの記事

Answer 7

Rob が前の回答で述べたように、m_ を使用し、その後わずかに修正された Simonyi 表記を使用します。したがって、接頭辞は便利であり、m_ はあまり邪魔にならず、簡単に検索できるようです。

そもそもなぜ表記があるのでしょうか？そして、名前の大文字と小文字に依存する Microsoft の表記法推奨事項 (.NET の場合) に従わないのはなぜでしょうか。

最初に後者の質問:指摘したように、VB.NET は大文字と小文字を区別しません。データベースと (特に) DBA も同様です。customerID と CustomerID を (たとえば C# で) 正確に保持しなければならないと、頭が痛くなります。つまり、大文字と小文字の区別は表記法の一形式ではありますが、あまり効果的なものではありません。

接頭辞表記にはいくつかの点で価値があります。

1. IDE を使用せずに人間のコードの理解力が高まります。コードレビューと同様に、最初は紙に書いて行うのが最も簡単だと私は今でも思っています。
2. T-SQL または他の RDBMS ストアド プロシージャを作成したことがありますか?データベースの列名に接頭辞表記を使用することは、特にこの種の作業にテキスト エディタを使用するのが好きな人にとっては非常に役立ちます。

要するに、スマート IDE が利用できない開発環境がまだ存在するため、記法形式としてプレフィックスを付けることが役立つということです。IDE (ソフトウェア ツール) は、いくつかのショートカット (インテリセンス タイピングなど) を可能にしますが、開発環境全体を構成するものではないと考えてください。

IDE は、自動車が交通ネットワークであるのと同じように、統合開発環境です。より大きなシステムの一部にすぎません。私は、標識のある道路を走行するなどの「車」の慣習には従いたくないのですが、場合によっては、空き地を歩いたほうが早い場合もあります。変数の型付けを追跡するために IDE に依存することは、空き地を歩くのに車の GPS が必要になるようなものです。もちろん、小さなコース変更ごとに車に戻るよりも、ポータブル形式で知識 (「m_intCustomerID」を持つのは面倒かもしれませんが) を持っていた方が良いでしょう。

つまり、m_ 規則または「this」規則はどちらも読み取り可能です。私たちが m_ を気に入っているのは、簡単に検索でき、その後に変数の型を入力できるためです。プレーンなアンダースコアが他の多くのフレームワーク コード アクティビティで使用されていることに同意します。

Answer 8

C# を使用して、「m_」プレフィックスを次のように変更しました。 ただのアンダースコア, 、「m_」は C++ からの遺産.

Microsoft の公式ガイドラインでは、プレフィックスを使用しないように指示されています。 プライベートメンバーではキャメルケースを使用する そして public メンバーのパスカルケース. 。問題は、これが同じ情報源からの別のガイドラインと衝突することです。 すべてのコードを .NET で使用されるすべての言語と互換性のあるものにする必要があります。. 。たとえば、VB.NET では大文字と小文字の区別はありません。

したがって、私にとってはアンダースコアだけです。これにより、IntelliSense を介したアクセスも簡単になり、パブリック メンバーのみを呼び出す外部コードでは、見た目に煩雑なアンダースコアを確認する必要がなくなります。

アップデート：私はそうは思わない C# の「this.」プレフィックス 「私」を助けます。 VBでは、「me.age」と同じ「me.age」がまだ表示されます。

Answer 9

それは使用しているフレームワークによって異なります。MFC コードを書いている場合は、次を使用します m_ そしてハンガリー語表記。他のもの (STL/Boost であることが多い) の場合は、すべてのメンバー変数にアンダースコア接尾辞を追加し、ハンガリー語表記を気にしません。

MFC クラス

class CFoo  
{  
private:  
    int m_nAge;  
    CString m_strAddress;  
public:  
    int GetAge() const { return m_nAge; }  
    void SetAge(int n) { m_nAge = n; }  
    CString GetAddress() const { return m_strAddress;  
    void SetAddress(LPCTSTR lpsz) { m_strAddress = lpsz; }  
};

STLクラス

class foo  
{  
private:  
    int age_;  
    std::string address_;  
public:  
    int age() const { return age_; }  
    void age(int a) { age_ = a; }  
    std::string address() const { return address_; }  
    void address(const std::string& str) { address_ = str; }  
};

2 つの異なるスタイルというこれは少し奇妙に思えるかもしれませんが、私にとってはうまくいきます。MFC 自体と同じスタイルを使用しない多くの MFC コードを記述するのは単に見苦しいだけです。

Answer 10

メンバー変数には「m」を、(関数内の) パラメーターには「p」を接頭辞として付けます。したがって、コードは次のようになります。

class SomeClass {
    private int mCount;
    ...
    private void SomeFunction(string pVarName) {...}
}

これにより、変数の基本的なスコープがすぐにわかることがわかりました。接頭辞がない場合、それはローカルです。また、関数を読み取るときに、何が渡されるのか、何が単なるローカル変数なのかを考える必要もありません。

Answer 11

それは本当に言語に依存します。私は C++ を使うのですが、すべての前にアンダースコアを付けるのは少し難しいです。この言語は、場合によっては (スコープに応じて) 実装のためにアンダースコアで始まるものを予約しています。二重アンダースコア、またはその後に大文字が続くアンダースコアに対する特別な処理もあります。したがって、そのような混乱を避け、単純に他のプレフィックスを選択するだけだと思います。「m」はOKです。「m_」は少し多いですが、ひどいものでもありません。本当に好みの問題です。

ただし、_leadingUnderscore には注意してください。コンパイラやライブラリの内部にそのような名前が付けられているものがいかに多いか驚くでしょう。十分に注意しないと、事故や混同が発生する可能性が確実にあります。いやだっていうだけだよ。

Answer 12

ほとんどの場合、Python を使用します。Python では、現在のクラスのインスタンスの属性 foo にアクセスするには、self.foo を使用する必要があります。そうすることで、作業するインスタンスのローカル変数、パラメータ、属性を混乱させる問題が解決されます。
強制されるのは嫌いですが、一般的に私はこのアプローチが好きです。したがって、これを行うための私の理想的な方法は、それを行わず、メンバー変数をフェッチするために this または self に対して何らかの形式の属性アクセスを使用することです。そうすれば、名前をメタデータで乱雑にする必要がなくなります。

Answer 13

言語がサポートしている場合は、 これ または 自分 キーワードを指定した場合は、プレフィックスを使用せず、代わりにそのキーワードを使用します。

Answer 14

もう一つのトリックは 命名規則:

すべてのメンバー変数は通常どおり、接頭辞なしで名前が付けられます (または「this.」はプロジェクト内でそうするのが通常です)。

ただし、私のプロジェクトでは、これらのローカル変数には常に次の名前が付けられているため、ローカル変数と簡単に区別できます。

• ある何か：は 1 つのオブジェクトを表します。
• いくつかのたくさんのこと:オブジェクトのリスト。
• はA州または もっている何か：ブール状態の場合。

「a」、「some」、または「is/has」で始まらない変数はすべてメンバー変数です。

Answer 15

VB.NET では大文字と小文字が区別されないため、メンバー変数の前にアンダースコアを付け、名前の残りの部分をキャメルケースにします。プロパティ名は大文字にします。

Dim _valueName As Integer

Public Property ValueName() As Integer

Answer 16

私は接頭辞を使用しない人々と一緒にいます。

最近の IDE は非常に優れており、構文の色分け、マウスオーバーのツールチップ、定義への簡単なナビゲーションなど、変数に関する情報を一目で簡単に見つけることができます。

これは、変数のコンテキストや命名規則 (ローカル変数やプライベート フィールドの LowerCamelCase、プロパティやメソッドの UpperCamelCase など) やブール値の "hasXXXX" や "isXX" などから取得できるものに加えられます。

私は何年もプレフィックスを使用していませんでしたが、以前は「これ」でした。プレフィックスモンスターですが、絶対に必要でない限り、私はそれを外しました（ありがとう、resharper）。

Answer 17

私は変わり者で、メンバー変数の前にクラス名のイニシャル (キャメルケース) を付けています。

TGpHttpRequest = class(TOmniWorker)
strict private
  hrHttpClient  : THttpCli;
  hrPageContents: string;
  hrPassword    : string;
  hrPostData    : string;

Delphi の人々のほとんどは単に F を使用します。

TGpHttpRequest = class(TOmniWorker)
strict private
  FHttpClient  : THttpCli;
  FPageContents: string;
  FPassword    : string;
  FPostData    : string;

Answer 18

独身者 _ 視覚的な指標としてのみ使用されます。(C#)

• インテリセンスを使用してメンバーをグループ化するのに役立ちます。
• コードを読むときにメンバー変数を見つけやすくなります。
• ローカル定義を使用してメンバー変数を非表示にするのは困難です。

Answer 19

_ の代わりに this.

私が使う _ 代わりにあまりにも this. なぜならそれはただの 短い (4 文字数が少ない)、メンバー変数の優れた指標となります。さらに、この接頭辞を使用すると、名前の競合を回避できます。例：

public class Person {
  private String _name;

  public Person(String name) {
    _name = name;
  }
}

これと比較してください:

public class Person {
  private String name;

  public Person(String name) {
    this.name = name;
  }
}

最初の例の方が短くてわかりやすいと思います。

Answer 20

それは、どの言語で作業しているかによって異なります。

C# では、「this」接頭辞を使用して任意のメンバーを参照できます。「this.val」、これは接頭辞が必要ないことを意味します。VB には「Me」と同様の機能があります。

メンバーアクセスを示すための組み込みの表記法がある言語では、接頭辞を使用する意味がわかりません。他の言語では、その言語で一般に受け入れられている規則を使用するのが理にかなっていると思います。

組み込み表記法を使用する利点の 1 つは、クラスのプロパティやメソッドにアクセスするときに、それらの命名規則を損なうことなく組み込み表記法を使用できることです (これは、非プライベート メンバーにアクセスする場合に特に重要です)。何らかの種類のインジケーターを使用する主な理由は、クラス内で副作用が発生する可能性があることを示すフラグとして使用することです。そのため、フィールド/プロパティ/メソッドなどであるかどうかに関係なく、他のメンバーを使用するときにインジケーターを使用することをお勧めします。 。

Answer 21

ここでも多くの場合と同様に、キャメルケースとアンダースコアを使用します。私は C# を使用しており、コンストラクターで 'this' キーワードを避けることに慣れているため、アンダースコアを使用します。私はキャメルケースのメソッドスコープのバリアントなので、アンダースコアはその時点でどのスコープで作業しているかを思い出させます。それ以外の場合は、コード内にすでに明らかな不必要な情報を追加しようとしていない限り、問題はないと思います。

Answer 22

私は C++ で m_ perfix を使用していましたが、C# ではフィールドにキャメルケースを使用し、そのプロパティにパスカルケースを使用することを好みます。

private int fooBar;
public int FooBar
{
  get { return fooBar; }
  set { fooBar = value; }
}

Answer 23

私は m_ が好きですが、コードベースで慣例が使用されている限り、それは問題ありません。

Answer 24

mul_ の例は、Charles Simonyi の Apps ハンガリー語表記に向かっています。

私は物事をシンプルにすることを好むので、プレフィックスとして m_ を使用するのが好きです。

こうすることで、元の宣言を表示するにはどこにアクセスする必要があるのか​​が非常に簡単になります。

Answer 25

私は C++ では m_ を使用する傾向がありますが、Java や C# では m_ を省略しても構わないと思います。そしてそれはコーディング標準に依存します。アンダースコアと m_ が混在するレガシー コードの場合は、コードを 1 つの標準にリファクタリングします (適切なコード サイズが与えられた場合)。

Answer 26

私が使う @。

:D j/k -- ただし、言語に依存します。ゲッター/セッターがある場合、通常はプライベート メンバー変数の前に _ を置き、ゲッター/セッターは _ を除いた同じ名前になります。それ以外の場合は、通常は何も使用しません。

Answer 27

私自身のプロジェクトでは、接尾辞として _ を使用します (上記の Martin York のように、接頭辞としての _ はコンパイラ実装の C/C++ 標準で予約されています)。作業するときは i を使用します。 シンビアンプロジェクト.

Answer 28

Java では、一般的な規則の 1 つは、メンバー変数の前に「my」とUseCamelCaseForTheRestOfTheVariableName を付けることです。

Answer 29

必要ない場合はなし、そうでない場合は単一のアンダースコアを付けます。Python に適用されます。

Answer 30

本当にメンバー変数に接頭辞を付ける必要がある場合は、間違いなくこれを好むでしょう m_ 単なるアンダースコアに。アンダースコアだけでは可読性が低下し、C++ の予約語と混同される可能性があることがわかりました。

ただし、メンバー変数に特別な表記が必要かどうかは疑問です。IDE ヘルプを無視しても、ローカル変数とメンバー変数がなぜ混同されるのかは明らかではありません。