c＃のフィールドとメソッドの前にある「this」キーワードに関して、現在考えられているベストプラクティスは何ですか？

同じ名前の変数とフィールドを区別する必要がない限りthis.、C＃でフィールドまたはメンバーアクセスの前に配置することはありません。これはm_、C ++で一般的に使用されていたプレフィックスと同じであり、メンバーであると指定する必要がある場合、クラスが大きすぎると思います。

しかし、私のオフィスには多くの人々が強く反対しています。

現在のベストプラクティスと見なされるものは何this.ですか？

編集：明確にするために、私は絶対に使用することはm_なくthis.、絶対に必要な場合にのみ使用します。

フレームワークの設計ガイドラインに従って、パブリックフィールドまたは保護フィールドを参照する場合：

フィールド名にプレフィックスを使用しないでください。

たとえばm_、プレフィックスです。

したがって、フィールドの公開は、thisMSDNで説明されているように、キーワードの使用に役立ちます。

同様の名前で非表示になっているメンバーを修飾するには、たとえば：コピー

public Employee(string name, string alias) 
{
   this.name = name;
   this.alias = alias;
}

プライベートフィールドを参照するm_場合、必要に応じて使用できます。ただし、パブリックフィールドについては、ベストプラクティスに従うことをお勧めします。

個人的には、変数名にアンダースコアが嫌いです。私も一貫性を保とうとします。だから、this.name = name;パブリック/プライベートの両方のシナリオで動作するのは良い経験則です。

私たちのチームでは、大規模なクラスでthis.or Me.オブジェクト修飾子を使用する標準を採用し、ジュニア開発者が変数を見ただけで変数の正確/即時スコープを簡単に区別できるようにしています。

コード面では、これはまったく不要な影響ですが、最終的にはまったく同じMISLコードを生成するため、何もブロックしません。一部のジュニアで発見された当面の問題に対処したためにのみ採用しました。それを超えて、私はそれを含めるのに役立つとは思わない。

StyleCopはthis.So の使用を強制します。これをベストプラクティスと見なす場合（私はそうします）、使用this.はベストプラクティスです。

あなたが採用するスタイルはあなた次第であり、あなた自身のコーディング標準です。「ベスト」はあなたが定義するものです。ただ一貫してください。一貫性のない使い方をすると混乱を招くだけです。

私の理由は、使用するthis.とインスタンスプロパティを参照しているという事実が呼び出されるため、たとえば、（もしあればthis.x = ...）それらを変更しているという事実を強調するのに役立ちます。またthis.、メソッドを見るたびに静的になることはないという事実も強調しています。のようないくつかの規則を使用してm_もこれを行うことができますが、それを手動で行う場合はm_、静的にするか、クラスの外部から値を渡すメソッドをリファクタリングする場合、使用している場合は名前を変更することを忘れないでくださいthisその後、コンパイラーは強制的に変更を行います。

単純に使用する方thisが簡単です。間違えた場合はコードがコンパイルされず、使用するm_場合は手作業であり、ツールを活用しないためです。

使用することの良い点の1つは、m_小さなmインテリセンスを入力するとすぐにすべてのプライベート変数のリストが表示されることです。個人的には、それがプラスになると思います。同様の理由でs_、プライベート静的およびc_プライベート定数にも行きます。ハンガリー語の表記ですが、ある意味では、変数名に有用な意味を追加して、他のプログラマーがその名前からそれについて完全に明白ではないかもしれないことを伝えることができるという意味です。

メンバー変数と非メンバー変数は区別されるため、メンバー変数と非メンバー変数を区別する方法がないことに私は確かに同意しません。コードを読むとき、人々が区別するために何かをしないと、読むのが本当に難しくなります。使用するthis.ことは、必要以上にボイラープレートのように感じます。しかし、実際には、しばらくの間1つの方法でコーディングすると、それが正しいと考え、他のすべてが間違っていると思うようになると、個人的な趣味になります。スキームが正しければ、本当に重要なのは、チームの全員が一貫しているということだけです。

this明示的です。これは見逃せない光のサインです。

私はほとんどの場合、暗黙のコードよりも明示的なコードを好みます。それが私がthis頻繁に使用する理由です。私はそれをベストプラクティスと考えています。

私はいつも「これ」を使用します。推論は、2つの単純な事実に基づいています。

• コードを読むことは、コードを書くことよりも困難です。
• コードを書くよりも頻繁にコードを読みます。

「これ」を使用すると、読んでいる人（つまり、作成者だけでなく、実装の詳細が完全に忘れられてから6か月後に作成者が含まれる場合）に非常に明確になります。ここで話します。「m_」などは単なる規則であり、他の規則と同様に誤用される（またはまったく使用されない）可能性があります。コンパイル時または実行時に「m_」などを強制するものはありません。「これ」はより強力です。「m_」をローカル変数に設定すれば、コンパイラは文句を言いません。「これ」ではできません。

どちらかといえば、言語仕様で「これ」の使用が義務付けられなかったことを残念に思います。

素敵なボーナスとして、デバッグ時に「this」の上にマウスを移動（またはウォッチを追加）し、他のすべてのクラスメンバーの検査も取得できます-貴重な情報です。

このthisキーワードは、特に同じ名前の変数を使用してコンストラクターまたはメソッドを作成するときに、存在する2つの変数を区別するために使用されますが、同じ型を持つことができます。

例：

public class Example {

    string reason;
    string cause;

    Example (string reason, string cause) {
        this.reason = reason;
        this.cause = cause;
    }

    //<Setter> if you want to explicitly write your onw
    public void setReason(stirng reason) {
        this.reason = reason;
    }
}

これは（例this.reason = reason）基本的にパラメータの値をクラスの変数に割り当てます。this基本的にreason、パラメータブロックからクラスを取得します。

私もしばらくの間、それについて疑問に思っていました。javascriptで大規模なコーディングを行った後this.、c＃コードでより頻繁に使用することに気付きました（その前に、曖昧さを避けるためにコンストラクターまたは同様のメソッドでほぼ排他的に使用しました）。コードを少しだけ追加することでコードがより明確になります。さらに、クラスメンバー名をプレフィックスで切り詰めることなく、コンテキストが明確な場合や特に複雑なステートメントの場合は、メンバーを「短い方法で」使用することに戻ることができます。this.メソッドを追加したり、引数リストを長くしたり、多くのローカル変数を宣言したりした場合、コードを追加することで、コードが強制されたとしても、さらに明確になります。

しかし、個人的には、m_ハンガリー語のせいではなく、アンダースコアはタイプするのが苦手なので、接頭辞スタイルは絶対に嫌いです;）だから、私はそれを代替とは思わない。インテリセンスに関しては長所があることは認めますが、メンバー変数の最初の数文字を思い出せない場合、クラスは大きいと主張することができます。

クラスメンバーに単一の下線プレフィックスを優先します。_someVar;

どうして？最初は、スタック変数ではなく、メンバーであることを知っています。一目見ただけで便利。また、「this」キーワードに比べて混乱が少なくなります。

this.接頭辞/キーワードなど、必要でも結果を変更するものでもないものを使用することは、常に主観的です。しかし、私たちのほとんどはフィールドをローカル変数と区別したいということに同意できると思います。アンダースコアの接頭辞を使用するものもあります（これはいハンガリー語表記の一種です）、他のものはthis.キーワードをます。私は後者の一人です。それはすべて読みやすさと理解しやすさについてです。それがより明確であるか、より読みやすいなら、私は少し余分にタイプすることを決して気にしません。瞬く間にフィールドと変数を区別したい。

に似た名前のフィールドmyFieldと、パラメータ名およびローカル変数名も常に定義しますmyField。アンダースコアもプレフィックスもありません。thisフィールドを参照するすべての場所で使用します。このようにして、フィールドをローカル変数や引数と区別することができます。プレフィックスはありません。もちろん、このような場合にはthisキーワードが必要です：

public Person(string firstName)
{
    this.firstName = firstName;
}

したがって、私のプロパティは次のようになります（はい、ファイルの先頭にある無関係な場所ではなく、常にプロパティを持つフィールドを配置します）。

private string firstName;
public string FirstName
{
    get { return this.firstName; }
}

それはうまく読みます：この名を返します。

編集：私の答えは明らかに答えではありません。ここに編集があります。Microsoftコーディングガイドラインには次のように記載されています。

2.6命名

メンバー変数にはプレフィックスを使用しないでください（、m、s_など）。>ローカル変数とメンバー変数を区別する場合は、C＃で「this。」を使用し、VB.NETで「Me。」を使用する必要があります。

http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspxで見つけることができます

そのため、少なくともMSからは明確なガイドラインはないように思えますが、別の回答ではStyleCopがガイドラインになっていると述べています。これらのことには権限がありませんので、あなた自身の決心をするか、この場合はあなたのチームに屈することをお勧めします。それはそんなに大したことではありません。

私の最初の答え は個人的にあなたに同意しますが、おそらく2つの方法を相互に比較する読解テストは価値があるでしょう。それ以外の場合、これらのスタイルの物事は単なる混乱です。

私が従うべき大事なこと：私の意見では、人々はコードスタイルを不必要に複雑にしている。プライベート変数をクラスの一番上に配置して、常に上下にスクロールするようにします。

これは、「これが何であるか」という規則と、「何をする」という正しい命名規則の1つであると思います。明示的であることの上に簡潔さを優先すべきです。これは、動的言語で頻繁に繰り返されるレッスンです。すべての綿毛は必要ありません！

この。多くの場合、不要なノイズにつながる可能性があります。

私の解決策は次のとおりです。

• parameter_names_
• local_variables
• ANY_CONSTANT
• _private_members
• NonPrivateProperties
• _NonPrivateProperty //バッカー
• 私有財産
• _privateProperty //バッカー