“This” anahtar kelimesini ne zaman kullanıyorsunuz? [kapalı]

Başkalarının bu anahtar kelimeyi nasıl kullandığını merak ediyordum . Bunu yapıcılarda kullanma eğilimindeyim ama sınıf boyunca diğer yöntemlerde de kullanabilirim. Bazı örnekler:

Bir kurucuda:

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

başka yerde

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

Bu anahtar kelimenin C # içinde birkaç kullanımı vardır .

1. Benzer adla gizlenmiş üyelere hak kazanmak için
2. Bir nesnenin kendisini diğer yöntemlere parametre olarak geçirmesini sağlamak
3. Bir nesnenin kendisini bir yöntemden döndürmesi için
4. Dizin oluşturucuları bildirmek için
5. Uzatma yöntemlerini beyan etmek
6. Parametreleri yapıcılar arasında geçirmek
7. Değer türü (yapı) değerini dahili olarak yeniden atamak için .
8. Geçerli örnekte bir uzantı yöntemini çağırmak için
9. Kendini başka bir türe atmak için
10. Aynı sınıfta tanımlanan kurucuları zincirlemek

Kapsamlı olarak aynı ada sahip üye ve yerel değişkenlere sahip olmayan ilk kullanımdan kaçınabilirsiniz, örneğin, yerel değişkenlerle (deve de) çarpışmayı önlemek için ortak adlandırma kurallarını izleyerek ve alanlar (deve örneği) yerine özellikler (Pascal örneği) kullanarak durum). C # 3.0 alanları otomatik olarak uygulanan özellikleri kullanarak kolayca özelliklere dönüştürülebilir .

Bunu kulağa iğrenç geliyor demek istemiyorum, ama önemli değil.

Ciddi anlamda.

Önemli olan şeylere bakın: projeniz, kodunuz, işiniz, kişisel yaşamınız. Hiçbiri, alanlara erişimi nitelemek için "bu" anahtar kelimeyi kullanıp kullanmadığınız konusunda başarılı olamayacak. Bu anahtar kelime zamanında gönderiminize yardımcı olmaz. Hataları azaltmayacak, kod kalitesi veya sürdürülebilirliği üzerinde kayda değer bir etkisi olmayacaktır. Sana zam vermeyecek ya da ofiste daha az zaman geçirmene izin vermeyecek.

Gerçekten sadece bir stil sorunu. Eğer "bu" isterseniz, o zaman kullanın. Eğer yapmazsan, yapma. Doğru semantiği elde etmek için ihtiyacınız varsa kullanın. Gerçek şu ki, her programcının kendine özgü bir programlama tarzı vardır. Bu tarz, belirli bir programcının "estetik açıdan en hoş kodun" neye benzemesi gerektiği fikrini yansıtır. Tanım olarak, kodunuzu okuyan diğer tüm programcılar farklı bir programlama stiline sahip olacaktır. Bu, her zaman yaptığınız, diğer adamın beğenmediği veya farklı yapacağı bir şey olacağı anlamına gelir. Bir noktada bazı adam kodunuzu okuyacak ve bir şey hakkında homurdanacak.

Üzülmem. Ben sadece kendi zevkinize göre mümkün olduğunca estetik olarak kod emin olun. 10 programcıya kodu nasıl biçimlendireceğinizi sorarsanız, yaklaşık 15 farklı görüş alırsınız. Odaklanmak için daha iyi bir şey, kodun nasıl faktörlü olduğu. İşler soyutlanmış mı? Şeyler için anlamlı isimler seçtim mi? Çok fazla kod çoğaltma var mı? İşleri basitleştirmenin yolları var mı? Bunları doğru yapmak, bence, projeniz, kodunuz, işiniz ve yaşamınız üzerinde en büyük olumlu etkiye sahip olacak. Tesadüfen, muhtemelen diğer adamın en az homurdanmasına neden olur. Kodunuz çalışırsa, okunması kolay ve iyi faktörlü ise, diğer kişi alanları nasıl başlattığınızı incelemeyecektir. O sadece kodunu kullanacak, onun büyüklüğüne hayret edecek,

Sadece kesinlikle gerekli olduğunda, yani başka bir değişken diğerini gölgelediğinde kullanıyorum. Burada olduğu gibi:

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;
    }

}

Veya Ryan Fox'un işaret ettiği gibi, bunu bir parametre olarak geçirmeniz gerektiğinde. (Yerel değişkenlerin üye değişkenlere göre önceliği vardır)

Şahsen ben her zaman kullanmayı deneyin bu üye değişkenlere bahsederken. Kodu netleştirmeye ve daha okunabilir hale getirmeye yardımcı olur. Belirsizlik olmasa bile, kodumu ilk kez okuyan biri bunu bilmiyor, ancak bunun sürekli olarak kullanıldığını görürlerse, bir üye değişkenine bakıp bakmadıklarını bilecekler.

İhtiyacım olmasa bile bir örnek değişkenine her başvurduğumda kullanıyorum. Bence kodu daha açık hale getiriyor.

Bunu her zaman kullanmanın "en iyi uygulama" olduğunu söyleyen insanların hepsine inanamıyorum.

Corey örneğinde olduğu gibi belirsizlik olduğunda veya nesneyi Ryan örneğinde olduğu gibi parametre olarak geçirmeniz gerektiğinde "this" i kullanın . Aksi halde kullanmak için bir neden yoktur, çünkü kapsam zincirine dayalı bir değişkeni çözümleyebilmenin, onunla nitelendirilen değişkenlerin gereksiz olması gerektiği kadar açık olması gerekir.

DÜZENLEME: "this" ile ilgili C # belgeleri, "this" anahtar sözcüğü için - bahsettiğim iki öğenin yanı sıra - bir daha kullanımı belirtiyor - dizin oluşturucuları bildirmek için

DÜZENLEME: @Juan: Ha, ifadelerimde herhangi bir tutarsızlık görmüyorum - "this" anahtar sözcüğünü (C # belgelerinde belgelendiği gibi) kullanacağım 3 örnek var ve bunlar gerçekten ihtiyacınız olan zamanlar . Hiçbir gölgeleme olmadığında bir kurucudaki değişkenlerin önüne "bu" yapıştırmak, tuş vuruşlarının israfı ve onu okurken zamanımın kaybıdır, fayda sağlamaz.

StyleCop bana her söylediğinde kullanıyorum . StyleCop'a uyulmalıdır. Oh evet.

Geçerli nesneye başvurmanız gerektiğinde.

Özellikle kullanışlı bir senaryo, nesnenizin bir işlevi çağırması ve kendini bu işleve iletmek istemesidir.

Misal:

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

Her yerde de kullanma eğilimindeyim, sadece uğraştığımız örnek üyelerin açık olduğundan emin olmak için.

Belirsizlik olabileceği her yerde kullanıyorum (açıkçası). Sadece derleyici belirsizliği değil (bu durumda gerekli olacaktır), aynı zamanda koda bakan birisi için de belirsizlik.

Bu anahtar kelime için bir başka nadir kullanım, uygulayıcı sınıfın içinden açık bir arabirim uygulaması çağırmanız gerektiğidir. İşte örnek bir örnek:

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

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

İşte bunu kullanıyorum:

• Sınıftan Özel Yöntemlere Erişim (farklılaştırmak için)
• Geçerli nesneyi başka bir yönteme iletme (veya bir olay olması durumunda gönderen nesne olarak)
• Uzantı yöntemleri oluştururken: D

Bu özel alanlar için kullanmıyorum çünkü özel alan değişken adları alt çizgi (_) ile önek.

[C ++]

"Gerektiğinde kullan" tugayı kabul ediyorum. Kodu gereksiz yere bu şekilde süslemek harika bir fikir değildir, çünkü derleyici bunu yapmayı unuttuğunuzda sizi uyarmaz. Bu, bunun her zaman orada olmasını bekleyen insanlar için potansiyel karışıklık getirir , yani düşünmek zorunda kalacaklar .

Peki, ne zaman kullanırsın? Ben sadece bazı rastgele kod etrafında bir göz vardı ve bu örnekleri bulundu (Bunları yapmak ya da başka türlü iyi şeyler olup olmadığına karar vermiyorum):

• "Kendinizi" bir işleve geçirmek.
• Bir işaretçiye veya bunun gibi bir şeye "kendiniz" atama.
• Döküm, yani yukarı / aşağı döküm (güvenli veya başka türlü), sabitliği dökmek vb.
• Derleyici zorla çıkarmaya zorladı.

Her zaman kullanmalısınız, özel alanları ve parametreleri ayırmak için kullanmalıyım (çünkü adlandırma kurallarımız üye ve parametre adları için önek kullanmadığımızı belirtmektedir (ve bunlar internette bulunan bilgilere dayanmaktadır, bu yüzden bir en iyi pratik))

Aynı türden bir nesneye başvuru kabul eden bir işlevde, hangi nesneye, nereye atıfta bulunduğumu mükemmel bir şekilde açıklamak istiyorum .

Örneğin

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() ;
  }
} ;

(vs)

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

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

Bir bakışta hangi AABB'ye right()atıfta bulunuyor? thisBir berraklaştırıcıdan biraz ekler.

Jakub Šturc'un cevabında, yapılandırıcılar arasında veri aktarma konusundaki # 5'i muhtemelen küçük bir açıklama kullanabilirdi. Bu, aşırı yük kurucularında ve kullanımının thiszorunlu olduğu tek durumdur . Aşağıdaki örnekte, parametresiz yapıcıyı parametresiz yapıcıdan varsayılan bir parametreyle çağırabiliriz.

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

Bunu zaman zaman özellikle kullanışlı bir özellik olarak buldum.

Visual C ++ 'da liberal olarak kullanma alışkanlığım var çünkü bunu yapmak'> 'tuşuna bastığım IntelliSense olanları tetikleyecek ve tembelim. (ve yazım hatalarına eğilimli)

Ama kullanmaya devam ettim, çünkü küresel bir fonksiyondan ziyade bir üye fonksiyonunu çağırdığımı görüyorum.

_ İle alanları altını çizme eğilimindedir, bu yüzden bunu hiç kullanmanıza gerek yok. Ayrıca R # onları yine de yeniden düzenleme eğilimindedir ...

Ben hemen hemen sadece kullanmak bu aynı tip içinden bir tür özelliği başvuru yaparken. Başka bir kullanıcı belirtildiği gibi onlar ihtiyaç duymadan fark edilir bu yüzden, aynı zamanda yerel alanları altını bu .

Tek argüman polimorfizmi nedeniyle bir tarafın yöntemlerine konulması gereken simetrik işlemler dışında sadece gerektiğinde kullanıyorum:

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

[C ++]

Bu , çoğu zaman garip (kasıtsız, tehlikeli veya program için sadece zaman kaybı) şeyleri kontrol etmeniz ve önlemeniz gereken atama işlecinde kullanılır:

A a;
a = a;

Ödev operatörünüz yazılacak:

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 ++ derleyicisinde

C ++ derleyicisi hemen bulmazsa bir sembolü sessizce arar. Bazen, çoğu zaman iyidir:

• alt sınıfta aşırı yüklemediyseniz, ana sınıf yöntemini kullanarak.
• bir türün değerini başka bir türe yükseltmek

Ancak bazen, derleyicinin tahmin etmesini istemezsiniz. Derleyicinin başka bir sembolü değil, doğru sembolü almasını istiyorsunuz.

Benim için o zamanlar, bir yöntem içinde bir üye yöntemine veya üye değişkenine erişmek istediğim zamandır. Sadece printfbunun yerine yazdığım için rastgele sembollerin alınmasını istemiyorum print. this->printfderlemezdim.

Mesele şu ki, C eski kütüphaneleri (§), yıllar önce yazılmış eski kodlar (§§) veya kopyala / yapıştırmanın eski fakat hala aktif bir özellik olduğu bir dilde ne olabilir, bazen derleyiciye oynamamasını söyler fikir harika bir fikir.

Kullandığım nedenler bunlar this.

(§) benim için hala bir tür gizem, ama şimdi kaynağınıza <windows.h> başlığını eklediğinizin, tüm eski C kütüphaneleri sembollerinin küresel ad alanınızı kirletmesinin nedeni olup olmadığını merak ediyorum

(§§) "bir başlık eklemeniz gerekiyor, ancak bu başlığı dahil etmenin kodunuzu kıracağından, genel bir adla aptal bir makro kullandığından" farkına varmak, kodlayıcının hayatındaki Rus rulet anlarından biridir

'bu.' 'bu' sınıftaki üyeleri çok sayıda üyeyle bulmaya yardımcı olur (genellikle derin bir miras zincirinden dolayı).

CTRL + Space tuşlarına basmak bu konuda yardımcı olmaz, çünkü türleri de içerir; 'bu' olarak. SADECE üyeleri içerir.

Sonra ne olduğumu bir kez ben genellikle silmek: ama bu sadece benim tarzı kırma.

Tarz açısından, yalnız bir korucuysanız - karar verirsiniz; Bir şirket için çalışıyorsanız şirket politikasına sadık kalın (kaynak kontrolündeki öğelere bakın ve diğer insanların ne yaptığını görün). Üyeleri hak kazanmak için kullanma açısından, ikisi de doğru ya da yanlış değildir. Tek yanlış şey tutarsızlıktır - bu tarzın altın kuralıdır. Nit toplama başkalarını bırakın. Bunun yerine zamanınızı gerçek kodlama problemlerini düşünerek ve açıkça kodlayarak düşünün.

Her fırsatta kullanıyorum. Kodun daha okunabilir hale geldiğine ve daha okunabilir kodun daha az hataya ve daha fazla sürdürülebilirliğe eşit olduğuna inanıyorum.

Aynı kod tabanı üzerinde çalışan birçok geliştirici olduğunuzda, bazı kod yönergelerine / kurallarına ihtiyacınız vardır. Çalıştığım yerde 'this' i alanlar, mülkler ve etkinlikler üzerinde kullanmak istedik.

Bana göre bunu yapmak mantıklı, sınıf değişkenleri ve yöntem değişkenleri arasında ayrım yaptığınızda kodun okunmasını kolaylaştırıyor.

Altında çalıştığım kodlama standardına bağlı. Bir örnek değişkenini belirtmek için _ kullanırsak, "bu" gereksiz olur. _ Kullanmıyorsak, bunu örnek değişkenini göstermek için kullanma eğilimindeyim.

Bunu JohnMcG gibi Intellisense'i çağırmak için kullanıyorum , ama geri döndüm ve işim bittiğinde "this->" i sileceğim. Ben üye değişkenleri "m_" ile önek Microsoft kuralına uyuyorum, bu yüzden belge olarak bırakmak sadece gereksiz olacaktır.

1 - Ortak Java ayarlayıcı deyimi:

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

2 - Bu nesneyle bir işlevi parametre olarak çağırırken

notifier.addListener(this);

C ++ 'da daha önce bahsedilmemiş bir kullanım vardır ve bu, kendi nesnesine atıfta bulunmak veya alınan bir değişkenden bir üyeyi belirsizleştirmek değildir.

thisBağımlı olmayan bir adı, diğer şablonlardan devralan şablon sınıflarının içindeki bağımsız değişken bağımlı bir ada dönüştürmek için kullanabilirsiniz .

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
   }
}

Şablonlar iki geçişli bir mekanizma ile derlenir. İlk geçiş sırasında, yalnızca bağımsız değişkene bağımlı olmayan adlar çözümlenir ve denetlenirken, bağımlı adlar, şablon bağımsız değişkenlerini gerçekten değiştirmeden yalnızca tutarlılık açısından denetlenir.

Bu adımda, türü gerçekten değiştirmeden, derleyicinin ne base<T>olabileceğine dair neredeyse hiçbir bilgisi yoktur (temel şablonun uzmanlaşmasının, onu tamamen farklı türlere, tanımsız türlere dönüştürebileceğini unutmayın), bu yüzden bunun yalnızca bir tür olduğunu varsayar. . Bu aşamada, fprogramcı için doğal görünen bağımlı olmayan çağrı , derleyicinin, derivedörnekte bulunmayan ad alanlarının bir üyesi veya kapalı olarak bulması gereken bir simgedir ve şikayet edecektir.

Çözüm, bağımlı olmayan adı bağımlı bir ada fdönüştürmektir. Bu açıkça uygulandığı türü (belirterek, birkaç yönden yapılabilir base<T>::f--adding base<T>üzerinde sembol bağımlı kılan Tve derleyici sadece mevcut ve olacağı üstlenecek erteledi sonra ikinci geçiş için fiili kontrolü, argüman ikamesi.

İkinci yol, birden fazla argümanı veya uzun adı olan şablonlardan miras alırsanız çok daha sıralayıcı this->, sembolün önüne bir ekleme yapmaktır. Uyguladığınız şablon sınıfı bir bağımsız değişkene bağlı olduğundan (miras devralı olduğu base<T>) this->bağımsız değişkene bağımlıdır ve aynı sonucu alırız: this->fşablon parametresi değiştirildikten sonra ikinci turda kontrol edilir.

Kesinlikle zorunlu olmadıkça "bu" kullanmamalısınız.

Gereksiz ayrıntılarla ilişkili bir ceza vardır. Tam olarak olması gerektiği sürece ve artık gerekli olmayan kod için çaba göstermelisiniz.