下線を引くか引かないか、それが問題だ質問する

Question

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

どの表記法を使用するかは、実際には重要ではありません。プロジェクトで既に使用されているものを使用するか、新しいものを選択するだけです。結局のところ、それは細かいことにこだわるだけで、生産性とはまったく関係ありません。柔軟性は最も重要な資質です。あなたは傭兵であり、手に入れた武器で戦わなければなりません。

残りの部分は、非常に主観的な内容なので読まないでください。また、過激派であることも役に立ちません。

平和！

重要な更新 (2016 年 4 月 12 日):

.NET CoreFXチームの内部標準がアンダースコア表記の使用を主張する理由についての洞察は示されていません。ただし、ルール 3 をよく見ると、、、接頭辞のシステムがあり、そもそもなぜが選択されたのかを示唆していることが明らかに_なります。t_s__

_camelCase内部フィールドとプライベートフィールドにはを使用し、可能な場合は readonly を使用します。インスタンスフィールドには_、静的フィールドにはs_、スレッド静的フィールドにはのプレフィックスを付けますt_。静的フィールドで使用する場合は、readonlyの後にstatic(つまりstatic readonlyではなくreadonly static) を付ける必要があります。

絶対に必要な場合を除いては避けますthis.。

それで.NET CoreFXチームのように、パフォーマンスが重要なマルチスレッドのシステムレベルのコードに取り組んでいる場合、以下のことを強くお勧めします:

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

それ以外の場合は、以下をお読みください...

オリジナルの答え:

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

アンダースコア表記

プライベートフィールドの名前に「_」プレフィックスを使用することを推奨します
また、絶対に必要な場合を除いて「this」を決して使用してはならないとも書かれています。

この表記

インスタンスメンバーにアクセスするには、常に「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-記法は名前をそのまま保持します

認知負荷

アンダースコア表記は一貫性がなく、フィールドを特別な方法で扱うことになりますが、他のメンバーと一緒に使用することはできません。そのたびに、プロパティとフィールドのどちらが必要かを自問する必要があります。
this表記は一貫しており、考える必要はなく、常に「this」を使用して任意のメンバーを参照するだけです。

メンテナンス

更新：指摘されているように、以下は利点ではありません

アンダースコア表記では、リファクタリング中に注意を払う必要があります_。たとえば、フィールドをプロパティに変換する（削除_）か、その逆（追加_）です。

この表記法にはそのような問題はない

自動補完

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

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

曖昧さ

場合によっては、Intellisense の助けを借りずにコードを処理する必要があります。たとえば、コードレビューを行うときや、オンラインでソースコードを参照するときなどです。

アンダースコア表記は曖昧です。Something.SomethingElse を見ると、Something がクラスで SomethingElse がその静的プロパティなのか、それとも Something が SomethingElse という独自のプロパティを持つ現在のインスタンスプロパティなのかはわかりません。
this 表記は明確です。Something.SomethingElse と表示された場合、それは静的プロパティを持つクラスのみを意味し、this.Something.SomethingElse と表示された場合、Something がメンバーであり、SomethingElse がそのプロパティであることがわかります。

拡張メソッド

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

アンダースコア記法では「this」を使用してはいけませんが、拡張メソッドでは
this 表記法を使用すると、ためらうことなく、常に「this」を使用できます。

Visual Studio サポート

アンダースコア表記はVisual Studioに組み込まれたサポートがありません
this 表記は Visual Studio によって自然にサポートされます。
1. 「これ。」資格:this.C#では、非静的メソッドで使用されるすべての非静的フィールドには、前置詞を付けることをお勧めします。

公式推奨事項

特にC#では「アンダースコアを使用しないでください」と明確に述べている公式ガイドラインがたくさんあります。

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

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

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

Answer 1