下線を引くか、下線を引かないか、それが問題です

バイナリバージョンが他のフレームワーク言語で使用される場合、C＃でプライベートフィールドの先頭にアンダースコアを付けないことで問題はありますか？たとえば、C＃では大文字と小文字が区別されるため、フィールド "foo"とパブリックプロパティ "Foo"を呼び出すことができ、正常に機能します。

これは持っているだろう任意の名前がケーシングによってのみ区別される場合は任意のCLS準拠（または他の）問題によって、このようVB.NETなど、大文字と小文字を区別しない言語に効果があるのだろうか？

効果はありません。

CLS準拠のライブラリを作成するための推奨事項の一部は、ケースによってのみ異なる2つのパブリック/保護されたエンティティを持たないことです。たとえば、

public void foo() {...}

そして

public void Foo() {...}

ライブラリのユーザーがプライベートアイテムを利用できないため、あなたが説明していることは問題ではありません

重要な更新（2016年4月12日）：

.NET CoreFXチームの内部標準は、理由に関する洞察を与えることなく、アンダースコア表記を使用することを主張していることが注目されました。我々はルール＃3をよく見ればしかし、それはのシステムがあることが明らかになり_、t_、s_なぜ示唆プレフィックス_最初の場所に選ばれましたが。

3. 私たちは、使用し_camelCase、内部および民間分野のため、可能であれば読み取り専用使用します。プレフィックスインスタンスフィールドには_、静的フィールドにはs_、スレッド静的フィールドにはを付けt_ます。静的フィールドで使用した場合、readonly後に来る必要がありますstatic（つまりstatic readonlyませんreadonly static）。
4. this.どうしても必要な場合以外は避けます。

したがって、.NET CoreFXチームがパフォーマンスクリティカルなマルチスレッドのシステムレベルのコードに取り組んでいる場合は、次のことを強くお勧めします。

• コーディング標準に準拠し、
• アンダースコア表記を使用し、
• これ以上この回答を読まないでください

そうでなければ読んでください...

元の答え：

まず、私たちが話していることについて合意しましょう。問題は、可視性修飾子が許可する場合に、クラス/サブクラスの非静的メソッドおよびコンストラクター内からインスタンスメンバーにアクセスする方法です。

アンダースコア表記

• プライベートフィールドの名前に「_」プレフィックスを使用することを提案します
• また、絶対に必要な場合を除いて、「this」は使用しないでください。

この表記

• 常に「これ」を使用することをお勧めします。インスタンスメンバーにアクセスする

なぜこの表記が存在するのですか？

これがあなたのやり方だから

• 同じ名前を共有する場合、フィールドからパラメータを区別する
• 現在のインスタンスのコンテキストで作業していることを確認してください

例

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

なぜアンダースコア表記が存在するのですか？

「これ」と入力したくない人もいますが、フィールドとパラメータを区別する方法が必要なので、フィールドの前に「_」を使用することに同意しました

例

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

個人的な好みの問題だと思うかもしれませんが、どちらも同じように良い/悪いです。ただし、この表記がアンダースコア表記に勝る特定の側面があります。

明快さ

• アンダースコア表記は名前を混乱させる
• この表記は名前をそのまま保持します

認知負荷

• アンダースコア表記は一貫性がなく、フィールドを特別な方法で扱いますが、プロパティとフィールドのどちらが必要かを自問する必要があるたびに、他のメンバーで使用することはできません

• この表記は一貫しており、考える必要はありません。常に「this」を使用して任意のメンバーを参照します

更新：指摘されたように、以下は有利な点ではありません

メンテナンス

• アンダースコア表記では_、リファクタリング中も注意を払う必要があります。たとえば、フィールドをプロパティに変更する（remove _）またはその逆（add _）などです。

• この表記にはそのような問題はありません

オートコンプリート

インスタンスメンバーのリストを表示する必要がある場合：

• 「_」を入力すると、オートコンプリートポップアップにプライベートフィールドと、残りのインスタンスメンバーと混合したリンクアセンブリから利用可能なすべてのタイプが表示されるため、アンダースコア表記はあまり役に立ちません
• this-notationは明確な答えを与えます。「this」と入力すると、表示されるのはメンバーのリストだけで、それ以外は何も表示されません。

あいまいさ

Intellisenseの助けなしにコードを処理しなければならない場合があります。たとえば、コードレビューを行ったり、ソースコードをオンラインで閲覧したりする場合です。

• underscore-notationがあいまいです：Something.SomethingElseが表示されても、Somethingがクラスであり、SomethingElseがその静的プロパティであるかどうかはわかりません...または、Somethingは、SomethingElseの独自のプロパティを持つ現在のインスタンスプロパティです

• この表記は明確です。Something.SomethingElseが表示された場合、それは静的プロパティを持つクラスのみを意味し、this.Something.SomethingElseが表示された場合、Somethingがメンバーであり、SomethingElseがそのプロパティであることがわかります。

拡張メソッド

「this」を使用せずにインスタンス自体で拡張メソッドを使用することはできません。

• アンダースコア表記では、「this」を使用しないことが必要ですが、拡張メソッドでは、
• この表記はためらいからあなたを救います、あなたはいつも「これ」の期間を使います。

Visual Studioのサポート

• underscore-notationにはVisual Studioの組み込みサポートがありません

• この表記は、Visual Studioによって自然にサポートされます。

  1. "この。" 資格：非静的メソッドで使用されるすべての非静的フィールドをthis.、C＃で前置することを推奨

公式の推奨事項

特にC＃では、「アンダースコアを使用しない」と明記されている多くの公式ガイドラインがあります。

• アンダースコア表記は、名前の競合を回避するのに役立つ一般的な方法であるC ++から来たものであり、VisualBasic.Netがフィールド「値」とプロパティ「値」が実際に同じ名前を持つという問題を克服することもお勧めします。大文字と小文字を区別しません

  1. Visual Basicで宣言された要素名
  2. VisualBasic.NETのバッキングフィールド

• この表記はC＃に推奨されますが、「_」は明示的に禁止されています。

  1. C＃のこのキーワード
  2. フィールドの使用ガイドライン：フィールド名または静的フィールド名に接頭辞を適用しないでください。
  3. 名前のためのガイドライン：型メンバの名称：フィールド名の接頭辞を使用しないでください。
  4. 一般的な命名規則：Xには、アンダースコア、ハイフン、またはその他の英数字以外の文字を使用しないでください
  5. 品質アサーションルールCA1707：識別子にアンダースコアを含めることはできません
  6. アンダースコアの使用はCLSに準拠していません（パブリックおよび保護された識別子の場合）
  7. .NET Framework開発者の内部命名規則：メンバー変数に接頭辞を使用しないでください。ローカル変数とメンバー変数を区別したい場合は、「this」を使用する必要があります。C＃と「私」で。VB.NET。

Microsoft StyleCopヘルプファイルから取得：

TypeName： FieldNamesMustNotBeginWithUnderscore

CheckId： SA1309

原因： C＃のフィールド名はアンダースコアで始まります。

ルールの説明：

このルールの違反は、フィールド名がアンダースコアで始まる場合に発生します。

デフォルトでは、StyleCopは、アンダースコアやm_などを使用してローカルクラスフィールドをマークし、「this」を優先します。接頭辞。「これ」を使用する利点。これは、フィールドだけでなく、メソッド、プロパティなどを含むすべての要素タイプに等しく適用され、コードの表示に使用されているエディターに関係なく、クラスメンバーへのすべての呼び出しを即座に認識できることです。もう1つの利点は、インスタンスメンバーと静的メンバーをすばやく認識できる区別ができることです。

フィールドまたは変数の名前がWin32またはCOMに関連付けられたアイテムの名前と一致することが意図されているため、アンダースコアで始める必要がある場合は、フィールドまたは変数を特別なNativeMethodsクラス内に配置します。NativeMethodsクラスは、NativeMethodsで終わる名前を含む任意のクラスであり、Win32またはCOMラッパーのプレースホルダーとして意図されています。アイテムがNativeMethodsクラス内に配置されている場合、StyleCopはこの違反を無視します。

異なるルールの説明は、上記に加えて、プライベートフィールドを小文字で開始し、パブリックフィールドを大文字で開始することを推奨していることを示しています。

編集：フォローアップとして、StyleCopのプロジェクトページはhttps://github.com/DotNetAnalyzers/StyleCopAnalyzersにあります。ヘルプファイルを読むと、さまざまなスタイルのルールを提案する理由がわかります。

ここではプライベートフィールドについて説明しているため、クラスのユーザーには影響しません。

ただし、プライベートフィールドにはアンダースコアを使用することをお勧めします。これにより、コードが理解しやすくなる場合があります。例：

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

私たちのチームでは、プライベートフィールドには常にアンダースコアプレフィックスを使用しています。したがって、コードを読み取るときに、プライベートフィールドを非常に簡単に識別して、ローカルや引数と区別することができます。ある意味で、アンダースコアは「this」の省略形と見なすことができます。

それ以来、非常に具体的で意味のないスタイルルールのある環境で作業した後、独自のスタイルを作成しました。これは、私が何度もめくったタイプの1つです。私は最終的にプライベートフィールドを常に_field、ローカル変数に_を含まない、小文字にすることを決定しました。コントロールの変数名はハンガリー語表記に緩やかに従い、パラメーターは通常camelCaseになります。

this.私の意見では、コードノイズが多すぎるというキーワードを嫌っています。私はリシャーパーの冗長なこれを削除するのが大好きです。キーワード。

6年の更新：Dictionary<TKey,T>同時アクセスの特定の使用法について 内部を分析し、プライベートフィールドをローカル変数であると誤って読みました。プライベートフィールドは、ローカル変数と同じ命名規則であってはなりません。アンダースコアがあった場合、それは信じられないほど明白だったでしょう。

アンダースコアが好きです。小文字の名前をメソッドパラメータとして次のように使用できるからです。

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

マーティンが述べた理由と、プライベートフィールドがIntelliSenseで一緒に並べ替えられるため、プライベートフィールドの前でアンダースコアを使用することは今でも本当に好きです。これは、一般にハンガリー語の接頭表記の悪さにもかかわらずです。

しかし、最近では、理由はよくわかりませんが、プライベートメンバーにアンダースコアプレフィックスを使用することは難しいと感じています。おそらく他の誰かが知っていますか？それは単に接頭辞の原則ですか？または、コンパイルされたアセンブリなどでアンダースコアが含まれるジェネリック型の名前のマングリングに関係するものはありましたか？

スタイルコップの推奨かどうかに関係なく、.NET Frameworkを掘り下げると、メンバー変数の多くの "_"の使用法が示されます。Style Copの作成者が何を推奨しても、それはMSの従業員の大多数が使用しているものではありません。:)だから私はアンダースコアに固執します。私は個人的にアンダースコアを使用することでミスを大幅に減らすため、これを使用します（例：this.varName = varNameの代わりにvarName = varNameを使用すると、本当に私に詰まっています）

概して、クラスレベルのフィールドは、言語の設計の誤りだと思います。C＃のプロパティに独自のローカルスコープがある場合は、それを優先します。

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

これにより、フィールドの使用を完全に停止することができます。

プライベートフィールドの先頭にアンダースコアを付けるのは、プロパティが別のバッキングフィールドを必要とするときだけです。それは私がプライベートフィールドを使用する唯一の時間でもあります。（そして、私は保護フィールド、内部フィールド、またはパブリックフィールドを決して使用しないので、フィールドのピリオドを使用するのはこのときだけです。）限り、変数がクラススコープを持つ必要がある場合、それはクラスのプロパティです。

プライベートフィールドの_fieldName表記は、簡単に解読できます。「これ」を使う。表記を壊すことは不可能です。_表記をどのように破りますか？観察する：

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

これで、命名規則に違反しましたが、コンパイルされます。私は、a）ハンガリー語ではなく、b）明示的な命名規則を使用したいと思います。私はハンガリーの命名をやめることに賛成であり、これはある意味で適格です。変数名の前にあるオブジェクトのタイプの代わりに、アクセスレベルがあります。

これをRubyと比較してください。変数@my_numberの名前はスコープに名前を結び付けており、壊れません。

編集：この答えは否定的になりました。私は気にしません、それは残ります。

アセンブリをCLS準拠にする場合は、assemblyinfoファイルでCLSCompliant属性を使用できます。次に、コンパイラーは、コードにcls準拠ではないものが含まれていると文句を言います。

次に、大文字と小文字のみが異なる2つのプロパティがある場合、コンパイラはエラーを発行します。一方、同じクラスにプライベートフィールドとパブリックプロパティがある場合は問題ありません。

（しかし、私は常にプライベートメンバーの前にアンダースコアを付けます。また、特定の変数がメンバーフィールドであることをコードを読んだときに、それを明確にするのにも役立ちます）。

2つの理由から、プライベートフィールドの前にアンダースコアを使用するのが好きです。1つはすでに言及されていますが、フィールドはコードおよびIntellisenseの関連プロパティから際立っています。2番目の理由は、VBとC＃のどちらでコーディングしても、同じ命名規則を使用できるためです。

何の影響もありません。コードがコンパイルされるとき、コンパイラーにとって重要なのはフィールド/プロパティの名前空間と可視性だけです。識別子に名前を付ける場合、アンダースコアは他の文字と同じくらい重要です。本当のトリックは、あなたとあなたの周りの人々が理解する慣習を使用することです。