coding-style - メンバー変数にはどのようなプレフィックスを使用していますか?

Question

「通常の」変数と簡単に区別できるように、メンバー変数に接頭辞を付けることがコードを理解する上で不可欠であることは間違いありません。

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

私はm_をプレフィックスとして使用するプロジェクトに取り組んできましたが、他のプロジェクトではアンダースコアのみを使用しました (アンダースコアのみでは十分に実証できないため、個人的には好きではありません)。

別のプロジェクトでは、変数の型も含む長いプレフィックス形式を使用しました。たとえば、mul_はunsigned long 型のメンバー変数のプレフィックスです。

使用しているプレフィックスの種類を教えてください (その理由を教えてください)。

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

score 55 · Accepted Answer

「通常の」変数と簡単に区別できるように、メンバー変数に接頭辞を付けることがコードを理解する上で不可欠であることは間違いありません。

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

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

別の編集：このように考えてください。変数の型とスコープは二次的な情報です。利用可能で簡単に見つけられるはずですが、大声で怒鳴られることはありません。のようなプレフィックスm_やタイプを使用するLPCSTRと、主要な情報 (コードの意図) を読みたいだけのときに、ノイズになります。

3 番目の編集: これは言語に関係なく適用されます。

score 46 · Accepted Answer

接頭辞は一切使いません。ローカル変数またはメソッドパラメーターをクラスメンバーと混同する危険に遭遇した場合、メソッドまたはクラスのいずれかが長すぎるため、分割することでメリットが得られます。

これにより、(ほぼ間違いなく) コードが読みやすくなり、ある程度「流暢」になるだけでなく、最も重要なこととして、適切に構造化されたクラスとメソッドが促進されます。結局のところ、接頭辞または接頭辞なしのジレマとはまったく異なる問題に要約されます。

更新: まあ、味と好みは変わりますよね..長期的にはローカル変数とメンバー変数を認識するのに有益であることが証明されているため、メンバー変数のプレフィックスとしてアンダースコアを使用するようになりました。特に新しいチームメンバーは、この 2 つを簡単に認識できない場合に苦労することがあります。

score 42 · Accepted Answer

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

score 22 · Accepted Answer

アンダースコアのみ。

私の場合、それを使用しているのは、私の職場のコーディング標準文書にそう書かれているからです。ただし、変数の先頭に m_ や恐ろしいハンガリー語を追加するポイントがわかりません。ミニマリストの「アンダースコアのみ」により、読みやすくなっています。

score 20 · Accepted Answer

何よりも一貫性を保つことが重要です。そのため、あなたとチームメイトが同意できるものを選び、それに固執してください。また、コーディングしている言語に慣習がある場合は、それに従うようにしてください。一貫性のないプレフィックス規則に従っているコードベースほど混乱を招くものはありません。

C++ の場合、_ がコンパイラキーワードのプレフィックスになることがあるという事実以外に、_ よりも m_ を優先する別の理由があります。m はメンバー変数を表します。これにより、ローカル変数と他のクラスの変数 (静的変数の場合は s_、グローバル変数の場合は g_) の間のあいまいさを解消することもできます (ただし、もちろんグローバル変数は使用しないでください)。

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

score 12 · Accepted Answer

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

なぜなら：

最近の IDE では、this.ポップアップ intellinsenseを入力しています
定義された命名を知らなくても、誰にとっても明らかです

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

score 7 · Accepted Answer

前の応答でRobが言ったように、m_を使用してから、わずかに変更されたSimonyi表記を使用します。したがって、プレフィックスは便利なようで、m_はあまり煩わしくなく、簡単に検索できます。

なぜ表記なのか？そして、名前の大文字小文字の区別に依存するMicrosoft表記の推奨事項（.NETの場合）に従わないのはなぜですか？

最初の後半の質問：指摘されているように、VB.NETはケーシングに無関心です。データベースと（特に）DBAもそうです。customerIDとCustomerID（たとえば、C＃）をまっすぐに保つ必要がある場合、脳が痛くなります。したがって、ケーシングは表記法の形式ですが、あまり効果的なものではありません。

プレフィックス表記には、いくつかの点で価値があります。

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

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

IDEは、自動車が輸送ネットワークであるのと同じように統合開発環境であり、より大きなシステムの一部にすぎません。マークされた道路にとどまるような「車」の慣習には従いたくありません。空き地を歩くだけの方が速い場合もあります。変数の入力を追跡するためにIDEに依存することは、車のGPSが空き地を歩く必要があるようなものです。もちろん、小さな変更のたびに車に戻るよりも、ポータブルな形式で知識（「m_intCustomerID」を持っていると厄介かもしれませんが）を持っている方が良いです。

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

score 6 · Accepted Answer

'm_' はC++ から継承されているため、C# を使用して、'm_' プレフィックスから単なるアンダースコアに移動しました。

公式の Microsoft ガイドラインでは、プレフィックスを使用せず、プライベートメンバーには camel-case を、パブリックメンバーには pascal-caseを使用するように指示されています。問題は、これが、.NET で使用されるすべての言語と互換性のあるすべてのコードを作成する必要があると述べている、同じソースからの別のガイドラインと衝突することです。たとえば、VB.NET ではケースの違いはありません。

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

更新: C# の "this." プレフィックスが "Me." に役立つとは思いません。VB では、"Me.age" は "Me.Age" と同じように表示されます。

score 5 · Accepted Answer

使用しているフレームワークによって異なります。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コードを書くことはただ醜く見えます.

score 4 · Accepted Answer

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

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

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

score 3 · Accepted Answer

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

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;

score 3 · Accepted Answer

それは本当に言語に依存します。私は C++ 派なので、すべての前にアンダースコアを付けるのは少し難しいです。言語は、場合によっては (スコープに応じて) 実装用にアンダースコアで始まるものを予約します。二重下線、または下線の後に大文字が続く場合も、特別な扱いがあります。ですから、その混乱を避けて、他の接頭辞を選択するだけです。「m」は大丈夫です。「m_」は少し多めですが、ひどいものでもありません。本当に好みの問題です。

ただし、これらの _leadingUnderscores には注意してください。コンパイラーとライブラリーの内部構造にそのような名前が付けられていることに驚かれることでしょう。細心の注意を払わないと、間違いなく事故や混同の余地があります。いやだっていうだけだよ。

score 3 · Accepted Answer

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

score 3 · Accepted Answer

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

score 2 · Accepted Answer

私は接頭辞を使わない人たちと一緒です。

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

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

私は何年も接頭辞を使用していませんでしたが、以前は「これ」でした。プレフィックスモンスターですが、どうしても必要な場合を除いて省略しました（ありがとう、Resharper）。

score 2 · Accepted Answer

`_`それ以外の`this.`

私は_代わりに tooを使用していますが、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;
  }
}

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

score 2 · Accepted Answer

視覚的なインジケータとしてのみ使用される単一の_ 。(C#)

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

score 2 · Accepted Answer

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

Dim _valueName As Integer

Public Property ValueName() As Integer

score 2 · Accepted Answer

別のトリックは命名規則です:

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

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

何か: 1 つのオブジェクトを表します。
some ManyThings: オブジェクトのリスト。
AState であるか、ブール値の状態の SomeThing: を持っています。

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

score 1 · Accepted Answer

以前はC++でm_perfixを使用していましたが、C＃では、フィールドにキャメルケースを使用し、プロパティにパスカルケースを使用することを好みます。

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

score 1 · Accepted Answer

私は m_ が好きですが、コードベースで規則が使用されている限り、私はそれでクールです.

score 1 · Accepted Answer

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

C# では、'this' プレフィックス ('this.val' など) を使用して任意のメンバーを参照できます。これは、プレフィックスが不要であることを意味します。VB には、「Me」と同様の機能があります。

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

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

score 1 · Accepted Answer

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

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

score 0 · Accepted Answer

私自身のプロジェクトでは、_ を接尾辞として使用し (Martin York が上記で述べたように、_ はコンパイラ実装の C/C++ 標準によって予約されているプレフィックスとして)、Symbian プロジェクトで作業する場合は i を使用します。

score 0 · Accepted Answer

あなたの mul_ 例は、Charles Simonyi の Apps Hungarian 表記に向かっています。

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

これを行うと、元の宣言を確認するためにどこに行かなければならないかを簡単に確認できます。

score 0 · Accepted Answer

私が使う @。

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

score -1 · Accepted Answer

プレフィックスなし。そして、純粋関数型/スタックベースの場合、変数名はありません。しかし、実際に副作用を使用する必要がある場合は、何かを出力したい場合p->は、pが関数に渡されるパラメーターへの外部ポインターである場合に使用します。

プレフィックス/プレフィックスの使用はばかげていると思います。

__EXTERN_GLOBAL_hungariannotationvariabletypeVendorName-my_member_prefix-Category-VariableName

mulの例を検討すると、multiply命令のオペコードを表すunsignedlongである私のメンバー変数はmulmulである可能性があります。

score -1 · Accepted Answer

メンバー変数のプレフィックスが本当に必要な場合はm_、アンダースコアのみを使用することをお勧めします。アンダースコア自体が読みやすさを低下させ、C++ の予約語と混同される可能性があることがわかりました。

ただし、メンバー変数に特別な表記が必要であるとは思えません。IDE ヘルプを無視しても、何がローカル変数で何がメンバー変数であるかが混同される理由は明らかではありません。

score -1 · Accepted Answer

Symbian では、メンバーの接頭辞として「i」を使用し、パラメータには「a」を使用します。

score -1 · Accepted Answer

必要でない場合はなし、それ以外の場合は単一のアンダースコア。パイソンに適用されます。

score -1 · Accepted Answer

私は _サフィックスのみを使用します(プレフィックス _ は、多くの人が上記で指摘したように c/c++ で予約されています)。私は主に「aCircle」のようなパラメーター名が嫌いで、絶対に必要でない限り、this.circle を書き出すのが好きではないので、これが好きです。(私は、パブリックアクセスメンバー変数に対してのみこれを行います。これらの変数には、アンダースコアのサフィックスを使用しません)。

coding-style - メンバー変数にはどのようなプレフィックスを使用していますか?

33 に答える 33

_それ以外のthis.

Related

Reference

`_`それ以外の`this.`