Kapan Anda menggunakan kata kunci "ini"? [Tutup]

Saya ingin tahu tentang bagaimana orang lain menggunakan kata kunci ini . Saya cenderung menggunakannya dalam konstruktor, tetapi saya juga dapat menggunakannya di seluruh kelas dalam metode lain. Beberapa contoh:

Dalam konstruktor:

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

Di tempat lain

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

Ada beberapa penggunaan kata kunci ini di C #.

1. Untuk memenuhi syarat anggota yang disembunyikan dengan nama yang mirip
2. Untuk memiliki objek lulus sendiri sebagai parameter ke metode lain
3. Untuk memiliki objek mengembalikan dirinya dari suatu metode
4. Untuk mendeklarasikan pengindeks
5. Untuk mendeklarasikan metode ekstensi
6. Untuk melewatkan parameter antara konstruktor
7. Untuk menetapkan kembali nilai jenis (struct) nilai secara internal .
8. Untuk memanggil metode ekstensi pada instance saat ini
9. Untuk melemparkan sendiri ke tipe lain
10. Untuk rantai konstruktor didefinisikan di kelas yang sama

Anda dapat menghindari penggunaan pertama dengan tidak memiliki variabel anggota dan lokal dengan nama yang sama dalam cakupan, misalnya dengan mengikuti konvensi penamaan umum dan menggunakan properti (case Pascal) alih-alih bidang (case unta) untuk menghindari bertabrakan dengan variabel lokal (juga unta kasus). Dalam C # 3.0 bidang dapat dikonversi ke properti dengan mudah dengan menggunakan properti yang diimplementasikan otomatis .

Saya tidak bermaksud ini terdengar aneh, tapi itu tidak masalah.

Serius.

Lihatlah hal-hal yang penting: proyek Anda, kode Anda, pekerjaan Anda, kehidupan pribadi Anda. Tak satu pun dari mereka akan memiliki kesuksesan mereka bergantung pada apakah Anda menggunakan kata kunci "ini" atau tidak untuk memenuhi syarat akses ke bidang. Kata kunci ini tidak akan membantu Anda mengirim tepat waktu. Itu tidak akan mengurangi bug, itu tidak akan memiliki efek yang berarti pada kualitas kode atau pemeliharaan. Itu tidak akan membuat Anda mendapatkan kenaikan gaji, atau memungkinkan Anda untuk menghabiskan lebih sedikit waktu di kantor.

Ini benar-benar hanya masalah gaya. Jika Anda suka "ini", maka gunakan. Jika tidak, maka jangan. Jika Anda membutuhkannya untuk mendapatkan semantik yang benar maka gunakanlah. Yang benar adalah, setiap programmer memiliki gaya pemrograman yang unik. Gaya itu mencerminkan gagasan programmer tertentu tentang seperti apa "kode yang paling menyenangkan secara estetika" seharusnya. Menurut definisi, setiap programmer lain yang membaca kode Anda akan memiliki gaya pemrograman yang berbeda. Itu berarti akan selalu ada sesuatu yang Anda lakukan yang tidak disukai orang lain, atau akan dilakukan secara berbeda. Pada titik tertentu seseorang akan membaca kode Anda dan menggerutu tentang sesuatu.

Saya tidak akan khawatir. Saya hanya akan memastikan kodenya senyaman mungkin sesuai dengan selera Anda. Jika Anda bertanya kepada 10 programmer bagaimana memformat kode, Anda akan mendapatkan sekitar 15 pendapat berbeda. Hal yang lebih baik untuk difokuskan adalah bagaimana kode diperhitungkan. Apakah hal-hal itu disarikan dengan benar? Apakah saya memilih nama yang bermakna untuk sesuatu? Apakah ada banyak duplikasi kode? Apakah ada cara saya bisa menyederhanakan hal-hal? Saya rasa, melakukan hal-hal itu akan memiliki dampak positif terbesar pada proyek Anda, kode Anda, pekerjaan Anda, dan kehidupan Anda. Secara kebetulan, itu mungkin juga akan menyebabkan orang lain menggerutu sedikit. Jika kode Anda berfungsi, mudah dibaca, dan difaktorkan dengan baik, orang lain tidak akan meneliti bagaimana Anda menginisialisasi bidang. Dia hanya akan menggunakan kode Anda, takjub akan kebesaran itu,

Saya hanya menggunakannya ketika benar-benar diperlukan, yaitu, ketika variabel lain membayangi yang lain. Seperti di sini:

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

}

Atau seperti yang ditunjukkan oleh Ryan Fox, ketika Anda perlu memberikan ini sebagai parameter. (Variabel lokal memiliki prioritas di atas variabel anggota)

Secara pribadi, saya mencoba untuk selalu menggunakan ini ketika merujuk ke variabel anggota. Ini membantu memperjelas kode dan membuatnya lebih mudah dibaca. Bahkan jika tidak ada ambiguitas, seseorang membaca kode saya untuk pertama kalinya tidak tahu itu, tetapi jika mereka melihat ini digunakan secara konsisten, mereka akan tahu apakah mereka sedang melihat variabel anggota atau tidak.

Saya menggunakannya setiap kali saya merujuk ke variabel instan, bahkan jika saya tidak perlu. Saya pikir itu membuat kode lebih jelas.

Saya tidak percaya semua orang yang mengatakan menggunakannya selalu adalah "praktik terbaik" dan semacamnya.

Gunakan "ini" ketika ada ambiguitas, seperti dalam contoh Corey atau ketika Anda harus melewatkan objek sebagai parameter, seperti dalam contoh Ryan . Tidak ada alasan untuk menggunakannya sebaliknya karena dapat menyelesaikan variabel berdasarkan rantai lingkup harus cukup jelas sehingga variabel yang memenuhi syarat dengannya tidak perlu.

EDIT: Dokumentasi C # tentang "ini" menunjukkan satu penggunaan lagi, selain dua yang saya sebutkan, untuk kata kunci "ini" - untuk mendeklarasikan pengindeks

EDIT: @Juan: Huh, saya tidak melihat adanya ketidakkonsistenan dalam pernyataan saya - ada 3 contoh ketika saya akan menggunakan kata kunci "ini" (seperti yang didokumentasikan dalam dokumentasi C #), dan itu adalah saat ketika Anda benar - benar membutuhkannya . Menempel "ini" di depan variabel dalam konstruktor ketika tidak ada bayangan yang terjadi hanyalah buang-buang tombol dan buang waktu saya ketika membacanya, itu tidak memberikan manfaat.

Saya menggunakannya kapan pun StyleCop menyuruh saya. StyleCop harus ditaati. Oh ya.

Kapan saja Anda membutuhkan referensi ke objek saat ini.

Satu skenario yang sangat berguna adalah ketika objek Anda memanggil suatu fungsi dan ingin memasukkan dirinya ke dalamnya.

Contoh:

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

Saya cenderung menggunakannya di mana-mana juga, hanya untuk memastikan bahwa itu adalah jelas bahwa itu adalah anggota contoh yang kita hadapi.

Saya menggunakannya di mana saja mungkin ada ambiguitas (jelas). Tidak hanya kompiler ambiguitas (itu akan diperlukan dalam kasus itu), tetapi juga ambiguitas bagi seseorang yang melihat kode.

Penggunaan lain yang agak jarang untuk kata kunci ini adalah ketika Anda harus meminta implementasi antarmuka eksplisit dari dalam kelas implementasi. Inilah contoh yang dibuat-buat:

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

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

Inilah saat saya menggunakannya:

• Mengakses Metode Pribadi dari dalam kelas (untuk membedakan)
• Melewati objek saat ini ke metode lain (atau sebagai objek pengirim, jika terjadi peristiwa)
• Saat membuat metode ekstensi: D

Saya tidak menggunakan ini untuk bidang pribadi karena saya awali nama variabel bidang pribadi dengan garis bawah (_).

[C ++]

Saya setuju dengan brigade "gunakan saat Anda harus". Menghias kode yang tidak perlu dengan ini bukanlah ide yang bagus karena kompiler tidak akan memperingatkan Anda ketika Anda lupa melakukannya. Ini menimbulkan potensi kebingungan bagi orang-orang yang mengharapkan hal ini selalu ada, yaitu mereka harus memikirkannya .

Jadi, kapan Anda akan menggunakannya? Saya baru saja melihat-lihat beberapa kode acak dan menemukan contoh-contoh ini (saya tidak menilai apakah ini hal yang baik untuk dilakukan atau tidak):

• Melewati "diri sendiri" ke suatu fungsi.
• Menetapkan "diri sendiri" ke pointer atau sesuatu seperti itu.
• Casting, yaitu casting atas / bawah (aman atau tidak), mengusir ketegaran, dll.
• Compiler disambiguasi diberlakukan.

Anda harus selalu menggunakannya, saya menggunakannya untuk membedakan bidang dan parameter pribadi (karena konvensi penamaan kami menyatakan bahwa kami tidak menggunakan awalan untuk nama anggota dan parameter (dan mereka didasarkan pada informasi yang ditemukan di internet, jadi saya menganggap bahwa praktek terbaik))

Saya menggunakannya ketika, dalam fungsi yang menerima referensi ke objek dengan tipe yang sama, saya ingin membuatnya dengan sangat jelas objek yang saya maksud, di mana.

Sebagai contoh

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

Sepintas yang dimaksud AABB right()? The thismenambahkan sedikit clarifier a.

Dalam Jakub Šturc menjawab, # 5 tentang meneruskan data antar kontraktor mungkin bisa menggunakan sedikit penjelasan. Ini dalam konstruktor kelebihan beban dan merupakan kasus di mana penggunaan thisadalah wajib. Dalam contoh berikut ini kita dapat memanggil konstruktor parameter dari konstruktor tanpa parameter dengan parameter default.

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

Saya menemukan ini sebagai fitur yang sangat berguna pada kesempatan tertentu.

Saya terbiasa menggunakannya secara bebas di Visual C ++ karena melakukan hal itu akan memicu IntelliSense saya menekan tombol '>', dan saya malas. (dan rentan terhadap kesalahan ketik)

Tapi saya terus menggunakannya, karena saya merasa berguna untuk melihat bahwa saya memanggil fungsi anggota daripada fungsi global.

Saya cenderung menggarisbawahi bidang dengan _ jadi tidak benar-benar perlu menggunakan ini. Lagi pula, R # cenderung untuk menolak mereka ...

Saya cukup banyak hanya menggunakan ini ketika referensi jenis properti dari dalam jenis yang sama. Seperti yang disebutkan pengguna lain, saya juga menggarisbawahi bidang lokal sehingga mereka terlihat tanpa perlu ini .

Saya menggunakannya hanya bila diperlukan, kecuali untuk operasi simetris yang karena polimorfisme argumen tunggal harus dimasukkan ke dalam metode satu sisi:

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

[C ++]

ini digunakan dalam operator penugasan di mana sebagian besar waktu Anda harus memeriksa dan mencegah hal-hal aneh (tidak disengaja, berbahaya, atau hanya buang-buang waktu untuk program) seperti:

A a;
a = a;

Operator penugasan Anda akan ditulis:

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 pada kompiler C ++

Compiler C ++ akan mencari simbol secara diam-diam jika tidak segera menemukannya. Terkadang, sebagian besar waktu, itu baik:

• menggunakan metode kelas ibu jika Anda tidak kelebihannya di kelas anak.
• mempromosikan nilai suatu tipe ke tipe lain

Tetapi kadang-kadang, Anda hanya tidak ingin kompiler menebak. Anda ingin kompiler mengambil simbol yang benar dan bukan yang lain.

Bagi saya , saat-saat itu adalah ketika, dalam suatu metode, saya ingin mengakses metode anggota atau variabel anggota. Aku hanya tidak ingin beberapa simbol acak dijemput hanya karena saya menulis printfbukan print. this->printftidak akan dikompilasi.

Intinya adalah bahwa, dengan C legacy libraries (§), kode legacy ditulis bertahun-tahun yang lalu (§§), atau apa pun yang bisa terjadi dalam bahasa di mana copy / paste adalah fitur usang tetapi masih aktif, kadang-kadang, memberitahu kompiler untuk tidak bermain kecerdasan adalah ide bagus.

Inilah alasan saya menggunakan this.

(§) itu masih semacam misteri bagi saya, tapi sekarang saya bertanya-tanya apakah fakta Anda menyertakan tajuk <windows.h> di sumber Anda, adalah alasan semua simbol perpustakaan C warisan akan mencemari namespace global Anda

(§§) menyadari bahwa "Anda harus menyertakan tajuk, tetapi dengan memasukkan tajuk ini akan merusak kode Anda karena menggunakan beberapa makro bodoh dengan nama generik" adalah salah satu momen roulette Rusia dalam kehidupan seorang pembuat kode.

'ini.' membantu menemukan anggota di kelas 'ini' dengan banyak anggota (biasanya karena rantai warisan yang dalam).

Memukul CTRL + Space tidak membantu dengan ini, karena juga termasuk tipe; dimana-seperti 'ini.' termasuk anggota SAJA.

Saya biasanya menghapusnya setelah saya mendapatkan apa yang saya inginkan: tetapi ini hanya gaya saya menerobos.

Dalam hal gaya, jika Anda seorang penjaga sendirian - Anda memutuskan; jika Anda bekerja untuk perusahaan tetap pada kebijakan perusahaan (lihat hal-hal dalam kendali sumber dan lihat apa yang dilakukan orang lain). Dalam hal menggunakannya untuk memenuhi syarat anggota, tidak ada yang benar atau salah. Satu-satunya hal yang salah adalah inkonsistensi - itu adalah aturan gaya emas. Biarkan nit-picking yang lain. Luangkan waktu Anda merenungkan masalah pengkodean nyata - dan jelas pengkodean - sebagai gantinya.

Saya menggunakannya setiap kali saya bisa. Saya percaya itu membuat kode lebih mudah dibaca, dan kode lebih mudah dibaca sama dengan lebih sedikit bug dan lebih mudah dirawat.

Ketika Anda banyak pengembang yang bekerja pada basis kode yang sama, Anda memerlukan beberapa panduan / aturan kode. Di tempat saya bekerja, kami memutuskan untuk menggunakan 'ini' di bidang, properti, dan acara.

Bagi saya itu masuk akal untuk melakukannya seperti ini, itu membuat kode lebih mudah dibaca ketika Anda membedakan antara variabel kelas dan variabel metode.

Tergantung pada standar pengkodean yang sedang saya kerjakan. Jika kita menggunakan _ untuk menunjukkan variabel instan maka "ini" menjadi redundan. Jika kita tidak menggunakan _ maka saya cenderung menggunakan ini untuk menunjukkan variabel instan.

Saya menggunakannya untuk memanggil Intellisense seperti JohnMcG , tapi saya akan kembali dan menghapus "ini->" ketika saya selesai. Saya mengikuti konvensi Microsoft tentang awalan variabel anggota dengan "m_", jadi meninggalkannya sebagai dokumentasi hanya akan menjadi berlebihan.

1 - idiom penyetel Java umum:

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

2 - Saat memanggil fungsi dengan objek ini sebagai parameter

notifier.addListener(this);

Ada satu penggunaan yang belum disebutkan dalam C ++, dan itu bukan untuk merujuk ke objek sendiri atau mendisambiguasikan anggota dari variabel yang diterima.

Anda bisa menggunakan thisuntuk mengonversi nama yang tidak tergantung menjadi nama yang bergantung argumen di dalam kelas templat yang mewarisi dari templat lain.

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

Template dikompilasi dengan mekanisme dua pass. Selama pass pertama, hanya nama-nama non-argumen yang dependen yang diselesaikan dan diperiksa, sementara nama-nama dependen hanya diperiksa untuk koherensi, tanpa benar-benar menggantikan argumen templat.

Pada langkah itu, tanpa benar-benar mengganti tipe, kompiler hampir tidak memiliki informasi tentang apa yang base<T>bisa (perhatikan bahwa spesialisasi template dasar dapat mengubahnya menjadi tipe yang sama sekali berbeda, bahkan tipe yang tidak terdefinisi), jadi ia hanya berasumsi bahwa itu adalah tipe . Pada tahap ini panggilan non-dependen fyang tampaknya wajar bagi programmer adalah simbol yang harus ditemukan oleh kompiler sebagai anggota derivedatau dalam melampirkan ruang nama - yang tidak terjadi dalam contoh - dan itu akan mengeluh.

Solusinya adalah mengubah nama yang tidak tergantung fmenjadi nama yang tergantung. Hal ini dapat dilakukan dalam beberapa cara, dengan secara eksplisit menyatakan jenis di mana ia diterapkan (- base<T>::fmenambahkan base<T>simbol membuat ketergantungan Tdan kompilator hanya akan menganggap bahwa itu akan ada dan menunda pemeriksaan aktual untuk lintasan kedua, setelah substitusi argumen.

Cara kedua, jauh lebih penyortir jika Anda mewarisi dari template yang memiliki lebih dari satu argumen, atau nama panjang, hanya menambahkan this->sebelum simbol. Sebagai kelas templat yang Anda laksanakan tergantung pada argumen (diturunkan dari base<T>) this->adalah bergantung pada argumen, dan kami mendapatkan hasil yang sama: this->fdicentang di babak kedua, setelah penggantian parameter templat.

Anda tidak boleh menggunakan "ini" kecuali Anda benar-benar harus.

ADA hukuman yang terkait dengan verbositas yang tidak perlu. Anda harus mengusahakan kode yang tepat asalkan diperlukan, dan tidak lagi.