「this」キーワードはいつ使用しますか？[閉まっている]

他の人がthisキーワードをどのように使用するのか知りたくて。コンストラクターで使用する傾向がありますが、クラス全体で他のメソッドで使用することもできます。いくつかの例：

コンストラクタで：

public Light(Vector v)
{
    this.dir = new Vector(v);
}

他の場所

public void SomeMethod()
{
    Vector vec = new Vector();
    double d = (vec * vec) - (this.radius * this.radius);
}

C＃では、このキーワードの使用法がいくつかあります。

1. 類似の名前で非表示になっているメンバーを修飾するには
2. オブジェクトが他のメソッドにパラメーターとして自分自身を渡すようにするには
3. オブジェクトがメソッドから自分自身を返すようにするには
4. インデクサーを宣言するには
5. 拡張メソッドを宣言するには
6. コンストラクター間でパラメーターを渡すには
7. 値タイプ（構造体）値を内部的に再割り当てします。
8. 現在のインスタンスで拡張メソッドを呼び出すには
9. 自分自身を別の型にキャストするには
10. 同じクラスで定義されたコンストラクターをチェーンするには

スコープ内に同じ名前のメンバー変数とローカル変数を持たないことで最初の使用を回避できます。たとえば、一般的な命名規則に従い、フィールド（キャメルケース）ではなくプロパティ（パスカルケース）を使用して、ローカル変数（ラクダ）との衝突を回避します。場合）。C＃3.0では、自動実装プロパティを使用してフィールドをプロパティに簡単に変換できます。

これがくしゃくしゃに聞こえるという意味ではありませんが、それは問題ではありません。

真剣に。

プロジェクト、コード、仕事、私生活など、重要なことを見てください。フィールドへのアクセスを修飾するために「this」キーワードを使用するかどうかに依存して、それらの成功はありません。thisキーワードは、時間どおりに出荷するのに役立ちません。バグを減らしたり、コードの品質や保守性に大きな影響を与えたりすることはありません。昇給したり、オフィスで過ごす時間を短縮したりすることはできません。

それは本当にただのスタイルの問題です。「これ」が好きなら、それを使ってください。そうでない場合は、しないでください。正しいセマンティクスを取得する必要がある場合は、それを使用してください。真実は、すべてのプログラマーが独自の独自のプログラミングスタイルを持っていることです。そのスタイルは、「最も美的に満足のいくコード」がどのように見えるべきかという特定のプログラマーの概念を反映しています。定義により、コードを読み取る他のプログラマーは、異なるプログラミングスタイルを使用することになります。つまり、他の人が気に入らない、または違ったことをしたことは常にあります。ある時点で、誰かがあなたのコードを読んで何かについて不平を言うでしょう。

私はそれを心配しません。自分の好みに応じて、コードが見た目に美しくなるようにします。10人のプログラマーにコードのフォーマット方法を尋ねると、約15の異なる意見が得られます。注目すべきより良いことは、コードがどのように因数分解されるかです。抽象化されたものは正しいですか？意味のある名前を付けましたか？コードの重複はたくさんありますか？単純化できる方法はありますか？これらのことを正しく行うことは、プロジェクト、コード、仕事、そして人生に最大のプラスの影響を与えると思います。偶然にも、それはおそらく他の人が少なくともつぶやくことも引き起こすでしょう。コードが機能し、読みやすく、十分に因数分解されている場合、他の人はフィールドを初期化する方法を詳しく調べません。彼はあなたのコードを使うだけで、その素晴らしさに驚嘆します。

絶対に必要な場合、つまり別の変数が別の変数をシャドウしている場合にのみ使用します。ここのような：

class Vector3
{
    float x;
    float y;
    float z;

    public Vector3(float x, float y, float z)
    {
        this.x = x;
        this.y = y;
        this.z = z;
    }

}

または、Ryan Foxが指摘するように、これをパラメーターとして渡す必要があります。（ローカル変数はメンバー変数よりも優先されます）

個人的には、メンバー変数を参照するときに常にこれを使用するようにしています。コードを明確にし、読みやすくします。あいまいさがなくても、私のコードを初めて読んだ人はそれを知りませんが、これが一貫して使用されているのを見ると、メンバー変数を見ているかどうかがわかります。

必要がない場合でも、インスタンス変数を参照するたびに使用します。コードがより明確になると思います。

いつも使うのが「ベストプラクティス」などと言う人すべてが信じられない。

Coreyの例のように曖昧な場合や、Ryanの例のようにオブジェクトをパラメータとして渡す必要がある場合は、「this」を使用します。スコープチェーンに基づいて変数を解決できることは十分明確である必要があるため、それを使用して変数を修飾する必要がないため、他の方法で使用する理由はありません。

編集：「this」に関するC＃のドキュメントは、「this」キーワードについて、私が言及した2つに加えて、インデクサーを宣言するためのもう1つの使用法を示しています

編集：@フアン：ええと、ステートメントに矛盾はありません-「this」キーワードを使用する場合（C＃のドキュメントに記載されているように）は3つのインスタンスがあり、実際にそれが必要な場合があります。シャドウイングが行われていないときにコンストラクターの変数の前に「this」を貼り付けることは、キーストロークの無駄であり、それを読み取るときの私の時間の無駄であり、メリットはありません。

StyleCopから指示されたときに使用します。StyleCopに従う必要があります。そうそう。

現在のオブジェクトへの参照が必要なときはいつでも。

特に便利なシナリオの1つは、オブジェクトが関数を呼び出していて、それを関数に渡したい場合です。

例：

void onChange()
{
    screen.draw(this);
}

私が扱っているのはインスタンスメンバーであることを明確にするためだけに、どこでも使用する傾向があります。

私は曖昧さがありそうなところならどこでもそれを使用します（明らかに）。コンパイラのあいまいさ（その場合は必要になります）だけでなく、コードを見ている人にとってもあいまいさがあります。

thisキーワードのもう少しまれな使用法は、実装クラス内から明示的なインターフェース実装を呼び出す必要がある場合です。これは不自然な例です：

class Example : ICloneable
{
    private void CallClone()
    {
        object clone = ((ICloneable)this).Clone();
    }

    object ICloneable.Clone()
    {
        throw new NotImplementedException();
    }
}

ここで私はそれを使用します：

• クラス内からプライベートメソッドにアクセスする（区別するため）
• 現在のオブジェクトを別のメソッドに渡す（またはイベントの場合は送信者オブジェクトとして）
• 拡張メソッドを作成するとき：D

私はプライベートフィールドの変数名の前にアンダースコア（_）を付けるため、これをプライベートフィールドには使用しません。

[C ++]

「必要なときに使う」旅団に同意します。これでコードを不必要に装飾することは良い考えではありません。コンパイラが警告をしなくても警告を表示しないからです。これは、これが常に存在することを期待する人々に潜在的な混乱をもたらします。つまり、彼らはそれについて考えなければならないでしょう。

では、いつそれを使用しますか？私はいくつかのランダムなコードを見回したところ、これらの例が見つかりました（これらが良いことかそうでないかについて、私は判断を下していません）：

• 関数に「自分」を渡す。
• 「自分」をポインタなどに割り当てる。
• キャスティング、つまりアップ/ダウンキャスティング（安全またはその他）、constnessのキャストなど
• コンパイラーは明確化を強制しました。

常に使用する必要があります。私はプライベートフィールドとパラメーターを区別するために使用します（私たちの命名規則では、メンバー名とパラメーター名に接頭辞を使用しないと記載されているため（そしてそれらはインターネット上で見つかった情報に基づいているため、ベストプラクティス））

同じタイプのオブジェクトへの参照を受け入れる関数で、どのオブジェクトをどこで参照しているかを完全に明確にしたいときに使用します。

例えば

class AABB
{
  // ... members
  bool intersects( AABB other )
  {
    return other.left() < this->right() &&
           this->left() < other.right() &&

           // +y increases going down
           other.top() < this->bottom() &&
           this->top() < other.bottom() ;
  }
} ;

（対）

class AABB
{
  bool intersects( AABB other )
  {
    return other.left() < right() &&
           left() < other.right() &&

           // +y increases going down
           other.top() < bottom() &&
           top() < other.bottom() ;
  }
} ;

AABBがright()参照する一目で？this清澄のビットを付加します。

JakubŠturcの回答では、コンストラクター間でのデータの受け渡しに関する彼の＃5は、おそらく少しの説明を使用できるでしょう。これはコンストラクターのオーバーロードであり、使用thisが必須である1つのケースです。次の例では、デフォルトパラメータを使用して、パラメータなしのコンストラクタからパラメータ化されたコンストラクタを呼び出すことができます。

class MyClass {
    private int _x
    public MyClass() : this(5) {}
    public MyClass(int v) { _x = v;}
}

これは特に便利な機能である場合があります。

Visual C ++で自由に使用する習慣がついたので、 '>'キーを押すとIntelliSenseがトリガーされ、怠惰になります。（そしてタイプミスが起こりやすい）

しかし、グローバル関数ではなくメンバー関数を呼び出していることがわかると便利なので、引き続き使用しました。

私は_でフィールドに下線を引く傾向があるので、これを実際に使用する必要はありません。また、R＃はとにかくそれらをリファクタリングする傾向があります...

私はほとんど同じタイプの内部からタイププロパティを参照するときにのみこれを使用します。別のユーザーが言ったように、私はローカルフィールドにも下線を引いているので、これを必要とせずに目立つようになります。

単一の引数の多相性のために片側のメソッドに配置する必要がある対称演算を除いて、必要な場合にのみ使用します。

boolean sameValue (SomeNum other) {
   return this.importantValue == other.importantValue;
} 

[C ++]

これは、ほとんどの場合、次のような奇妙な（意図しない、危険、またはプログラムの時間の無駄）をチェックして防止する必要がある代入演算子で使用されます。

A a;
a = a;

割り当て演算子が記述されます。

A& A::operator=(const A& a) {
    if (this == &a) return *this;

    // we know both sides of the = operator are different, do something...

    return *this;
}

this C ++コンパイラ

C ++コンパイラは、シンボルがすぐに見つからない場合に、黙ってそのシンボルを検索します。時々、ほとんどの場合、それは良いことです：

• 子クラスでオーバーロードしなかった場合は、母クラスのメソッドを使用します。
• 型の値を別の型に昇格させる

しかし、時々、コンパイラに推測させたくないだけです。コンパイラが正しいシンボルをピックアップし、別のシンボルをピックアップしないようにします。

私にとって、それらの時は、メソッド内で、メンバーメソッドまたはメンバー変数にアクセスしたいときです。のprintf代わりに書いたからといって、ランダムなシンボルをピックアップしたくありませんprint。this->printfコンパイルされなかったでしょう。

ポイントは、Cレガシーライブラリ（§）、何年も前に書かれたレガシーコード（§§）、またはコピー/貼り付けが廃止されたがまだアクティブな機能である言語で起こり得ることで、コンパイラーに再生しないように指示することです機知は素晴らしいアイデアです。

これらが私が使用する理由ですthis。

（§）まだ謎ですが、ソースに<windows.h>ヘッダーを含めることが、従来のすべてのCライブラリシンボルがグローバルネームスペースを汚染する理由なのでしょうか。

（§§）「ヘッダーを含める必要がありますが、このヘッダーを含めると、一般的な名前のダムマクロが使用されるため、コードが破損します」というのは、コーダーの人生におけるロシアのルーレットの瞬間の1つです。

'この。' 多数のメンバーを持つ「this」クラスのメンバーを見つけるのに役立ちます（通常、継承チェーンが深いため）。

タイプも含まれているため、CTRL + Spaceを押しても問題は解決しません。where-として「これ」。メンバーのみが含まれます。

私は通常、自分が求めていたものを手に入れたら削除しますが、これは私のスタイルの突破口です。

スタイルの面では、あなたが孤独なレンジャーであるなら、あなたが決める; あなたが会社で働いているなら、会社の方針に固執してください（ソース管理のことを見て、他の人が何をしているかを見てください）。メンバーの資格取得に使用するという点では、どちらも正しいか間違っています。間違っているのは一貫性のなさだけです。それがスタイルの黄金律です。ほんの少しだけ摘み取ったままにしておきます。代わりに、実際のコーディング問題（そして明らかにコーディング）について熟考してください。

できる限り使用しています。これにより、コードが読みやすくなり、コードが読みやすくなると、バグが減り、保守性が向上します。

同じコードベースで作業する多くの開発者がいる場合、いくつかのコードガイドライン/ルールが必要です。私が作業する場所では、フィールド、プロパティ、およびイベントに「this」を使用することを考えました。

私にとっては、このようにするのは理にかなっています。クラス変数とメソッド変数を区別すると、コードが読みやすくなります。

それは私が働いているコーディング標準に依存します。インスタンス変数を示すために_を使用している場合、「this」は冗長になります。_を使用していない場合、これを使用してインスタンス変数を表す傾向があります。

JohnMcGと同じようにIntellisenseを呼び出すために使用しますが、完了したら「this->」を削除して消去します。私は、メンバー変数の前に「m_」を付けるというMicrosoftの規則に従っているので、ドキュメントのままにしておくのは冗長です。

1-一般的なJavaセッターイディオム：

 public void setFoo(int foo) {
     this.foo = foo;
 }

2-このオブジェクトをパラメーターとして使用して関数を呼び出す場合

notifier.addListener(this);

C ++でまだ言及されていない用途が1つあります。これは、独自のオブジェクトを参照したり、受け取った変数からメンバーを明確にしたりすることではありません。

を使用thisして、他のテンプレートから継承するテンプレートクラス内で、非依存名を引数依存名に変換できます。

template <typename T>
struct base {
   void f() {}
};

template <typename T>
struct derived : public base<T>
{
   void test() {
      //f(); // [1] error
      base<T>::f(); // quite verbose if there is more than one argument, but valid
      this->f(); // f is now an argument dependent symbol
   }
}

テンプレートは、2パスメカニズムでコンパイルされます。最初のパスでは、非引数の依存名のみが解決およびチェックされますが、依存名は一貫性についてのみチェックされ、実際にテンプレート引数を置き換えることはありません。

その段階では、型を実際に置き換えることなく、コンパイラーは何base<T>ができるかについての情報をほとんど持っていません（基本テンプレートを特殊化すると、それを完全に異なる型に、未定義の型にでも変換できることに注意してください）。 。この段階ではf、プログラマーderivedにとっては自然に思える非依存呼び出しは、コンパイラーが名前空間のメンバーとして、または名前空間を囲む際に見つけなければならないシンボルです（例では発生しません）。

解決策は、非依存名fを依存名に変えることです。これは、実装されているタイプを明示的に示すことで、いくつかの方法で実行できます（-をbase<T>::f追加するbase<T>と、シンボルが依存しT、コンパイラーはそれが存在すると想定し、2番目のパスの実際のチェックを延期します。引数の置換。

2番目の方法は、複数の引数または長い名前を持つテンプレートから継承する場合のより多くのソーターは、単にthis->記号の前にを追加することです。実装しているテンプレートクラスは引数に依存するため（それはから継承base<T>）this->、引数に依存し、同じ結果が得られthis->fます。テンプレートパラメーターの置換後、2番目のラウンドでチェックされます。

絶対に必要でない限り、「this」を使用しないでください。

不必要な冗長性に関連するペナルティがあります。あなたはそれが必要である限り正確に長く、もはやないコードのために努力するべきです。