Apa praktik terbaik yang saat ini dianggap terkait dengan kata kunci "ini" di depan bidang dan metode dalam c #?


14

Kecuali diperlukan untuk membedakan antara variabel dan bidang dengan nama yang sama, saya tidak pernah meletakkan this.di depan bidang atau akses anggota dalam C #. Saya melihat ini tidak ada bedanya dengan m_awalan yang dulu biasa di C ++, dan berpikir jika Anda benar-benar perlu menentukan bahwa itu adalah anggota, kelas Anda terlalu besar.

Namun, ada sejumlah orang di kantor saya yang sangat tidak setuju.

Apa yang dianggap praktik terbaik saat ini this.?

EDIT: Untuk memperjelas, saya tidak pernah menggunakan m_dan hanya menggunakan this.jika benar-benar diperlukan.


Apa yang m_seharusnya berarti?
FrustratedWithFormsDesigner

2
@Frustrated Bahwa variabel adalah anggota kelas.
Michael Todd

Maaf, saya membuat asumsi bahwa tidak ada yang bisa berpikir saya menggunakan notasi Hongaria. Saya mencoba mengatakan saya pikir this.hampir sama buruknya dengan m_.
Andy Lowry

3
Bung, cukup instal dan jalankan StyleCop! Ini juga pasti merupakan penipuan dari pertanyaan SO.
Ayub

3
Menyetujui atau tidak setuju dengan tim Anda tidak peduli, Anda masih membutuhkan konsistensi dalam tim. Terutama yang lebih besar dari tim jika tidak semua mau tak mau seperti barat liar dan Anda tahu apa yang orang katakan tentang coders Koboi. ;-)
Chris

Jawaban:


14

Menurut pedoman desain Kerangka , ketika merujuk ke bidang publik atau yang dilindungi:

JANGAN gunakan awalan untuk nama bidang.

Misalnya, m_adalah awalan.

Jadi, paparan publik bidang cocok untuk penggunaan thiskata kunci seperti yang dijelaskan pada MSDN

Untuk memenuhi syarat anggota yang disembunyikan dengan nama yang mirip, misalnya: Salin

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

Saat merujuk ke bidang pribadi, Anda dapat menggunakan m_jika Anda mau. Tapi, untuk bidang publik saya sarankan mengikuti praktik terbaik.

Secara pribadi, saya tidak suka garis bawah pada nama variabel saya. Saya juga berusaha konsisten. Jadi, this.name = name;adalah aturan praktis yang baik untuk bekerja dalam skenario publik / swasta.


+1: Ini yang saya maksudkan dalam jawaban saya, tetapi jawaban Anda jauh lebih deskriptif.
Joel Etherton

1
Setuju - Saya telah melihat beberapa skenario di mana Anda memiliki properti, anggota, dan variabel lokal semua dengan nama yang sama. Properti ini Pascal (huruf pertama ditulis dengan huruf besar) sehingga Anda memiliki dua variabel yang menggunakan Camel (huruf pertama lebih rendah). Satu-satunya cara untuk membedakan adalah dengan "ini." (disarankan) atau awalan (tidak disarankan). Saya telah menggunakan keduanya dan dalam praktiknya kata kunci ini membuatnya lebih mudah diikuti (IMO).
Mayo

1
Yang lucu dengan saran kerangka kerja adalah sumber CLR dikotori dengan m_awalan. Saya pikir '_' adalah awalan yang baik karena Anda tidak pernah khawatir tentang masalah stackoverflow dari kesalahan pengerjaan tugas
Chris S

@ Chris S - Dalam pengalaman saya Microsoft melakukannya dengan baik dengan mendokumentasikan dan memelihara "proses kode evolusi". Mereka telah menggunakan banyak praktik yang sekarang dianggap "praktik buruk". Kemungkinan besar karena mereka belajar dari kesalahan mereka. Ini tidak berarti mereka kembali dan mengubah kode yang ada karena tidak selalu sepadan dengan usaha. Pastikan untuk mengikuti pedoman terbaru dalam baru - kode aplikasi non-warisan.
P.Brian.Mackey

11

Di tim kami, kami telah mengadopsi standar penggunaan objek this.atau Me.kualifikasi di kelas yang lebih besar untuk membantu pengembang junior lebih mudah membedakan ruang lingkup variabel langsung / langsung hanya dengan melihatnya.

Dari segi kode, ini sepenuhnya merupakan pengaruh yang tidak perlu, tetapi tidak menghalangi apa pun karena ia menghasilkan kode MISL yang persis sama pada akhirnya. Kami mengadopsinya hanya karena itu mengatasi masalah langsung yang kami temukan dengan beberapa junior. Di luar itu, saya tidak melihatnya membantu untuk memasukkannya.


Poin bagus tentang junior coders.
Patrick Hughes

2
Bukankah seharusnya kelas Anda lebih kecil? Atau ini masalah warisan?
Tjaart

@ Metroart: Kelasnya besar atau kecil seperti yang seharusnya. Bahkan dalam kelas kecil dapat dengan mudah melupakan ruang lingkup variabel seperti yang muncul di layar.
Joel Etherton

1
Mengapa junior Anda mengalami masalah @JoelEtherton? Junior python memiliki masalah sebaliknya di mana mereka lupa menambahkan diri. untuk mengakses variabel pribadi. Bukankah para junior hanya melupakan dan mengacaukan konvensi?
Tjaart

1
@ Metroart: Terkadang. Mereka memiliki masalah karena mereka junior, dan kadang-kadang mereka hanya tidak memperhatikan atau belum memiliki mata yang terlatih. Kami menggunakan teknik ini lebih sebagai rambu daripada sebagai standar atau konvensi. Ini sebenarnya tidak digunakan di sini sejak pos ini sekarang karena semua junior kami telah terbiasa dengan lingkungan. Saya membayangkan jika kita menyewa junior baru (tidak mungkin dalam waktu dekat) mungkin akan kembali.
Joel Etherton

10

StyleCop akan menegakkan penggunaan this.Jadi, jika Anda menganggap itu sebagai praktik terbaik (yang saya lakukan), maka penggunaan this.praktik terbaik adalah.

Gaya yang Anda adopsi terserah Anda dan standar pengkodean Anda sendiri, "terbaik" adalah apa pun yang Anda tetapkan. Bersikaplah konsisten. Menggunakannya secara tidak konsisten hanya menimbulkan kebingungan.

Alasan saya adalah bahwa menggunakan this.memanggil fakta bahwa Anda mereferensikan properti instance, jadi, misalnya, akan membantu untuk menyoroti fakta bahwa Anda memutasikannya (jika sudah this.x = ...), yang merupakan sesuatu yang mungkin ingin Anda ketahui. Ini juga menyoroti fakta bahwa setiap kali Anda melihat this.metode Anda tidak akan pernah statis. Menggunakan beberapa konvensi seperti m_juga akan melakukan ini, tetapi ini adalah upaya manual, jika Anda membuat m_menjadi statis, atau refactor beberapa metode untuk meneruskan nilai dari luar kelas maka Anda harus ingat untuk mengubah nama, jika Anda menggunakan thismaka kompiler akan memaksa Anda untuk melakukan perubahan.

Sederhananya menggunakan thislebih mudah karena jika Anda salah kode Anda tidak akan dikompilasi, jika Anda menggunakannya m_adalah upaya manual dan Anda tidak memanfaatkan alat.


9
Dan Resharper akan menyarankan menghapus "ini." Jarak tempuh Anda mungkin beragam.
Carra

Eh? Resharper tidak pernah menyarankan itu padaku. Mungkin itu karena saya memiliki plugin StyleCop?
Jesse C. Slicer

1
Benar, menginstal StyleCop akan mematikan opsi itu di R #.
Steve

5

Salah satu hal yang menyenangkan tentang penggunaan m_adalah bahwa begitu Anda mengetik mintellisense kecil memberi Anda daftar semua variabel pribadi Anda, secara pribadi saya pikir itu merupakan nilai tambah dalam bantuan itu; Saya juga akan menggunakan s_statika pribadi dan c_konstanta pribadi untuk alasan yang sama. Ini adalah notasi Hungaria, tetapi dalam arti ini dimaksudkan karena ia menambah makna yang berguna untuk nama variabel sehingga setiap programmer lain dapat mengatakan hal-hal tentang itu dari namanya yang mungkin tidak sepenuhnya jelas.

Saya tentu saja tidak setuju dengan tidak memiliki cara untuk membedakan antara variabel anggota dan variabel non-anggota karena mereka berbeda dan ketika saya membaca kode di mana orang tidak melakukan sesuatu untuk menghancurkan itu benar-benar sulit untuk dibaca. Menggunakan this.hanya terasa seperti lebih banyak pelat ketel daripada yang diperlukan. Tapi sebenarnya itu adalah selera pribadi, jika Anda kode satu cara untuk sementara waktu Anda akhirnya berpikir itu benar dan yang lainnya salah. Satu-satunya hal yang benar-benar penting jika skema itu waras adalah semua orang di tim konsisten.


4
Atau ketik this.dan biarkan intellisense membantu Anda.
Steve

1
@Steve Haigh: Anda tidak mengerti intinya, dia mengatakan bahwa dia akan mengelompokkan semua jenis anggota yang berbeda bersama-sama, karena daftarnya diurutkan secara alfabet, semua m_ muncul bersama, semua s_ bersama dll.
gbjbaanb

2
menggunakan this.akan memberi Anda segala sesuatu di kelas tanpa perlu menggunakan konvensi penamaan yang ketinggalan zaman. Saya mengerti maksud dari berbagai surat, saya hanya berpikir itu tidak perlu. Jika Anda memiliki begitu banyak properti, konstanta dll dalam satu kelas yang Anda butuhkan konvensi ini maka desain Anda cukup banyak rusak.
Steve

2
@Steve Haigh: Sangat bagus di dunia teoretis di mana semua orang di tim adalah programmer yang hebat dan mereka semua membagi kelas mereka menjadi bongkahan kecil dan refaktor yang digigit dengan baik dan punya waktu untuk memikirkan desain dll ... Dalam pengalaman saya hidup tidak cukup keluar seperti itu. Tapi saya setuju di dunia ideal Anda mungkin benar.

@Steve: Mengetik m_akan memberi saya daftar semua variabel anggota. Mengetik this.akan memberi saya daftar variabel anggota dan fungsi anggota.
Sean

4

thiseksplisit. Ini adalah tanda optik yang tidak bisa Anda lewatkan.

Saya hampir selalu lebih suka kode eksplisit daripada kode implisit. Itu sebabnya saya thissering menggunakan . Saya menganggapnya sebagai praktik terbaik.


4

Saya selalu menggunakan "ini". Alasannya didasarkan pada dua fakta sederhana:

  • Membaca kode lebih sulit daripada menulis kode.
  • Anda membaca kode lebih sering daripada menulis kode.

Penggunaan "ini" membuatnya cukup eksplisit bagi siapa pun yang membaca (yaitu bukan hanya penulis, tetapi dapat memasukkan penulis dalam waktu 6 bulan setelah spesifikasi implementasi telah sepenuhnya dilupakan) bahwa ya, ini adalah anggota kelas yang kami ' sedang berbicara tentang di sini. "m_" dan sejenisnya hanyalah sebuah konvensi, dan seperti konvensi lainnya, konvensi ini dapat disalahgunakan (atau tidak digunakan sama sekali) - tidak ada yang dapat menegakkan "m _" / etc pada saat kompilasi atau run-time. "this" lebih kuat: Anda bisa meletakkan "m_" pada variabel lokal dan kompiler tidak akan mengeluh; Anda tidak dapat melakukannya dengan "ini".

Jika ada yang saya anggap menyesal bahwa penggunaan "ini" tidak diwajibkan dalam spesifikasi bahasa.

Sebagai bonus yang bagus, saat men-debug Anda dapat mengarahkan (atau menambahkan jam tangan) "ini" dan mendapatkan inspeksi dari semua anggota kelas lainnya juga - informasi yang berharga.


3

Kata thiskunci digunakan terutama untuk membedakan 2 variabel yang ada, terutama ketika melakukan Anda memiliki konstruktor atau metode dengan variabel dengan nama yang sama tetapi dapat memiliki jenis yang sama.

Contoh:

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

Ini (misalnya this.reason = reason) pada dasarnya memberikan nilai dari parameter ke variabel di kelas. thispada dasarnya mengambil kelas reasondari blok parameter.


2

Saya juga bertanya-tanya tentang hal itu selama beberapa waktu. Setelah melakukan beberapa pengkodean yang luas dalam javascript, saya this.lebih sering menggunakan kode c # saya (sebelum itu saya menggunakannya hampir secara eksklusif dalam konstruktor atau metode serupa untuk menghindari ambiguitas). Itu membuat kode sedikit lebih jelas untuk sedikit usaha tambahan, apalagi Anda tidak berakhir memutilasi nama anggota kelas Anda dengan awalan dan masih dapat kembali menggunakan anggota 'jalan pintas' ketika konteksnya jelas atau dalam pernyataan yang sangat kompleks. Saya hanya menambahkan this., ketika saya memiliki metode yang lebih panjang, daftar argumen yang lebih panjang atau banyak variabel lokal yang dideklarasikan dan saya pikir kode tersebut dapat mengambil keuntungan dari beberapa kejelasan tambahan, bahkan jika itu dipaksakan.

Tapi saya pribadi sangat membenci m_gaya awalan, bukan karena Hongaria, tetapi karena garis bawah adalah rasa sakit untuk mengetik;) Jadi saya tidak menganggapnya sebagai alternatif. Saya akui itu memiliki poin kuat dalam hal intellisense, namun Anda dapat kembali berargumen bahwa jika Anda tidak dapat mengingat beberapa huruf pertama dari variabel anggota, kelas Anda terlalu besar.


1

Saya memilih awalan garis bawah tunggal untuk anggota kelas. _someVar;

Mengapa? Anda tahu pada awalnya glace bahwa itu adalah anggota, bukan variabel tumpukan. Hanya kenyamanan selama sekilas. Dan itu membutuhkan lebih sedikit kekacauan dibandingkan dengan kata kunci "ini".


1

Menggunakan hal-hal seperti this.awalan / kata kunci yang tidak perlu atau mengubah hasilnya selalu subjektif. Namun, saya pikir kita dapat setuju bahwa sebagian besar dari kita ingin membedakan bidang dari variabel lokal. Beberapa menggunakan awalan garis bawah (yang saya temukan jelek dan semacam notasi Hungaria), yang lain menggunakan this.kata kunci. Saya salah satunya. Ini semua hanya tentang keterbacaan dan pemahaman. Saya tidak keberatan mengetik sedikit ekstra jika lebih jelas atau lebih mudah dibaca. Saya ingin membedakan bidang dan variabel dalam sekejap mata.

Saya selalu mendefinisikan bidang bernama mirip myFielddan nama parameter dan nama variabel lokal juga mirip dengan myField. Tidak ada garis bawah, tidak ada awalan. Saya menggunakan di thismana saja saya merujuk ke suatu bidang. Dengan cara ini saya bisa membedakan bidang dari variabel dan argumen lokal tanpa awalan apa pun. Tentu saja, dalam kasus seperti ini, thiskata kunci diperlukan:

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

Karena itu, properti saya terlihat seperti ini (ya, saya selalu meletakkan bidang dengan properti, dan bukan di tempat yang tidak terkait di bagian atas file saya):

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

Bunyinya bagus: kembalikan nama depan ini .


-2

EDIT: Jawaban saya jelas bukan jawaban. Jadi di sini adalah hasil edit. Status pedoman pengkodean Microsoft:

2.6 Penamaan

Jangan gunakan awalan untuk variabel anggota ( , m , s_, dll.). Jika Anda ingin membedakan> antara variabel lokal dan variabel anggota Anda harus menggunakan "ini." Dalam C # dan "Saya." Di VB.NET.

Dapat ditemukan di: http://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspx

Jadi akan terlihat bahwa setidaknya dari MS tidak ada pedoman yang jelas, meskipun jawaban lain menyatakan bahwa StyleCop membuatnya menjadi pedoman. Tidak ada wewenang untuk hal-hal ini, jadi saya sarankan Anda mengambil keputusan sendiri, atau dalam hal ini menyerah kepada tim Anda. Ini bukan masalah besar.

Jawaban asli saya, saya pribadi setuju dengan Anda, tetapi mungkin tes pemahaman membaca mengadu dua metode terhadap satu sama lain akan berharga. Kalau tidak, hal-hal gaya ini hanya mudslinging.

Salvo saya untuk mengikuti: Pendapat saya adalah bahwa orang tidak perlu memperumit gaya kode mereka, dan jika mereka perlu menunjukkan bahwa ada sesuatu yang merupakan variabel tingkat kelas mungkin ada beberapa masalah struktural serius lainnya dalam kode, seperti metode resep kuno yang sudah ada. menempatkan variabel pribadi di bagian atas kelas yang memaksa Anda untuk terus-menerus menggulir ke atas dan ke bawah.

ini mengejutkan saya sebagai salah satu dari konvensi penamaan "apa ini" versus konvensi yang benar "apa fungsinya". Singkatnya harus disukai di atas menjadi eksplisit. Ini adalah pelajaran yang sering diulang dengan bahasa dinamis. Kami tidak membutuhkan semua bulu-bulu!


1
-1. Alih-alih menjawab pertanyaan, Anda hanya memberikan pendapat yang tidak mencerminkan praktik terbaik.
Arseni Mourzenko

Jadi menurut penggunaan stylecop ini. adalah praktik terbaik @MainMa. Saya sangat tidak setuju. Saya akan mengedit jawaban untuk mencatat itu.
Tjaart

@ MainMa apakah itu lebih baik sekarang? Banyak jawaban lain hanya memberikan pendapat, tetapi tidak diturunkan. Apa praktik terbaik dan di mana mereka ditemukan?
Tjaart

-3

ini. Sering dapat menyebabkan kebisingan yang tidak diinginkan.

Inilah solusi saya:

  • parameter_names_
  • variabel local_
  • ANY_CONSTANT
  • anggota _private_members
  • NonPrivateProperties
  • _NonPrivateProperty // Pendukung
  • milik pribadi
  • _privateProperty // pendukung

2
Ini sangat bertentangan dengan gaya .Net umum. casing unta dan pascal semua jalan melalui. Metode Anda cukup tidak konsisten. Ini juga merupakan aturan gaya yang lama untuk mengkapitalkan konstanta, dan salah satu yang tidak digunakan dalam komunitas .Net umum.
Tjaart

Saya harap Anda memberikan komentar di bagian atas setiap file yang menjelaskan skema itu untuk yang belum tahu ... ;-)
JaySeeAre

Saya tidak mengerti bagaimana menurut Anda menambahkan ini. akan membuat kebisingan, tetapi semua omong kosong itu tidak
Travis Weston
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.