Mengapa Microsoft membuat parameter, variabel lokal, dan bidang pribadi memiliki konvensi penamaan nama yang sama?


18

Saya menanyakan pertanyaan ini beberapa waktu yang lalu: Bagaimana Anda memberi nama variabel pribadi Anda di C #?

Dalam salah satu jawaban, saya diarahkan ke halaman MSDN Microsoft yang menunjukkan bahwa variabel / bidang pribadi harus dinamai seperti ini:

private int myInteger;

Tetapi parameternya adalah:

void SomeMethod(int myInteger)

dan variabel lokal akan seperti ini:

int myInteger;

Jadi ketika Anda mereferensikannya seperti ini

myInteger = 10;

Anda tidak memiliki cara untuk mengetahui mana yang sedang Anda bicarakan.

Saya sekarang memulai proyek baru dan salah satu rekan kerja saya bertanya mengapa kami tidak melakukan sesuatu untuk membedakan setidaknya beberapa dari ini.

Saya bertanya-tanya hal yang sama. Mengapa standar Microsoft tidak membuat ini berbeda?


10
Apa maksud Anda "Anda tidak tahu apa yang Anda bicarakan"? Tentu saja Anda lakukan - ruang lingkup.
Thomas Owens

2
Panduan itu tampaknya sudah ketinggalan zaman, default resharper (yang telah menjadi semacam panduan gaya defacto) merekomendasikan awalan bidang pribadi dengan garis bawah yang merupakan hal yang selalu saya lakukan.

25
@kekekela: Sama sekali tidak ketinggalan jaman; StyleCop akan secara eksplisit menandai setiap instance variabel anggota yang dimulai dengan garis bawah. Terus terang saya menemukan garis bawah tidak ada gunanya dan menjengkelkan karena casing menyampaikan informasi yang sama persis. Jika Anda perlu membuat ruang lingkup eksplisit, maka penetapan awalan dengan this..
Aaronaught

12
@Aronaught saya menemukan banyak "ini" yang berlebihan. tersebar di sekitar kode saya tidak ada gunanya dan menjengkelkan.

12
@kekekela: Satu-satunya tempat saya pernah menemukan diri saya harus melakukannya adalah dalam constructor, dan dalam konstruktor itu masuk akal karena Anda benar-benar lewat di nilai-nilai yang menginisialisasi bidang anggota ( this.component = component). Jika Anda menemukan diri Anda dengan lingkup ambigu di tempat lain, sehingga Anda memiliki "banyak yang berlebihan ini." tersebar di sekitar kode Anda ", maka Anda memiliki kode yang ditulis dengan buruk.
Aaronaught

Jawaban:


14

Konvensi penamaan asli memiliki awalan m_ untuk anggota kelas, ini dikurangi menjadi garis bawah sederhana. Anda akan melihat banyak kode Microsoft C # yang lebih lama menggunakan awalan garis bawah. Namun, saya pernah mendengar di Tech Ed bahwa garis bawah utama tidak sesuai dengan CLS. Saya berasumsi inilah alasan mengapa mereka pindah ke skema satu nama yang cocok untuk semua. Dulu (tidak yakin sekarang) bahwa nama tidak sensitif case VB.Net juga tidak sesuai CLS.

Untuk apa nilainya, saya masih menggunakan garis bawah terkemuka untuk anggota kelas. Meskipun Anda dapat disambiguasi menggunakan this (this.name sebagai kebalikan dari nama), bug masih bisa menembus

Anda tidak harus melakukan semua yang diminta oleh MS.


1
Saya pikir Anda telah bingung "CLR-compliant" dengan "CLS-compliant". Jika sesuatu tidak sesuai CLR, itu tidak akan dikompilasi. CLS hanyalah peringatan bahwa itu mungkin tidak kompatibel dengan bahasa lain, dan pada dasarnya hanya mempengaruhi anggota publik (secara teknis, hal-hal yang terlihat di luar majelis Anda).
Joel C

@ Joel - Anda benar. Pertanyaan ini berkaitan dengannya: stackoverflow.com/questions/1195030/…
dave

2
Saya masih menggunakan awalan "m_" ...
CesarGon

4
+1 "karena Anda tidak harus melakukan semua yang MS minta Anda lakukan". Pikirkan dirimu sendiri!
gbjbaanb

1
Itu hanya tidak CLS-Compliant jika bidangnya protected, bukanprivate
Rachel

9

localdan parametervariabel diberi nama dengan cara yang sama karena cakupannya sama

Adapun variabel pribadi, ada pendapat berbeda tentang itu. Saya selalu menggunakan standar yang ditemukan di sini , yang menspesifikasikan untuk menggunakan yang terdepan _sebelum variabel pribadi, meskipun penulis mengatakan bahwa _itu agak kontroversial dan Microsoft merekomendasikan untuk tidak melakukannya.

Wikipedia menyatakan bahwa dalam C dan C ++

Nama-nama yang dimulai dengan garis bawah ganda atau garis bawah dan huruf kapital dicadangkan untuk implementasi (kompiler, pustaka standar) dan tidak boleh digunakan (mis. __Reerved atau _Rerverved).

jadi mungkin itulah alasan di balik Microsoft merekomendasikan hal itu, meskipun cukup diketahui bahwa banyak Microsoft devs menggunakan _awalan untuk variabel pribadi mereka.


2
Poin bagus tentang parameter dan variabel lokal memiliki cakupan yang sama (+1). Tidak ada yang menyebutkan itu. Yang wajar adalah bahwa jika Anda memerlukan variabel lokal dengan nama yang sama dengan parameter, Anda bisa menggunakan parameter. Secara pribadi saya menemukan garis bawah jelek dan tidak tepat. Padahal thispasti mengacu pada objek saat ini. Saya tidak mengerti kebencian this. Apakah itu karena disalahpahami?
Jason S

4

Saya tidak bisa memberi tahu Anda dengan pasti mengapa mereka tidak membuat mereka berbeda. Kemungkinan tidak ada yang bisa kecuali seseorang yang ikut menciptakan standar terjadi untuk melihat pertanyaan ini.

Banyak orang membuat konvensi mereka sendiri dengan memberi awalan variabel instan dengan _atau m_, tetapi saya benar-benar tidak menganggapnya penting. Anda dapat menyimpulkan banyak dari konteks dan IDE hari ini cukup pintar untuk membantu Anda. Visual Studio dengan addon ReSharper, misalnya, akan menunjukkan kepada Anda variabel lokal dan variabel instan dalam berbagai warna.

Jika benar-benar penting bahwa Anda membedakan antara dua cakupan, Anda bisa menggunakan this.awalan untuk merujuk ke variabel instance:

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Tanpa plugin lain, Visual Studio secara default akan membantu Anda dengan Intellisense:

tangkapan layar

(Munculan mungkin masih ditata oleh ReSharper di sana, tetapi ReSharper tidak menambahkan apa pun ke fitur-fitur Intellisense bawaan, jadi sementara stok yang mungkin terlihat sedikit berbeda, masih ada dua opsi di sana. )

Anda juga dapat menggunakan alat analisis kode seperti FxCop dan StyleCop untuk membantu Anda menangkap masalah potensial dengan penamaan dan ruang lingkup variabel.


Untuk sedikit menguraikan this, saya selalu lebih suka this, karena pasti mengacu pada contoh saat ini di rumah apa pun Anda berada, jadi itu tepat. Konvensi garis bawah atau garis bawah adalah hanya itu - konvensi yang mungkin atau mungkin tidak merujuk ke variabel instan dan dibuat berlebihan oleh this. Satu-satunya tempat yang saya lihat garis bawah berguna dalam VB case-insensitive untuk membedakan nama objek dan kelas. Tapi itu adalah cerita lain.
Jason S

4

Mengapa standar Microsoft tidak membuat ini berbeda?

Orang-orang di Microsoft menulis sebuah buku berjudul Kerangka Desain Pedoman yang menjelaskan sejumlah konvensi, termasuk mengapa beberapa hal dijadikan unta , dan yang lainnya dilakukan pascal .

Edit (menambahkan detail dari buku):

Dalam buku itu, mereka menyebutkan melakukan studi kegunaan, serta beberapa pelajaran yang didapat dari mengakuisisi kelompok Turbo Pascal. Selain itu, meskipun tidak semua bahasa peka terhadap huruf besar-kecil (seperti VB), bahasa lainnya (seperti C #), jadi seseorang harus konsisten dalam penamaannya. Seseorang tidak dapat bergantung pada perbedaan dalam kasus saja untuk membedakan item. Jika seseorang tetap pada konvensi yang digunakan oleh sisa kerangka kerja, itu akan menyebabkan lebih sedikit kebingungan oleh para dev.

Bab 3, Pedoman Penamaan.
Bagian 3.1 adalah konvensi kapitalisasi.

camelCasingadalah untuk nama parameter.
PascalCasingadalah untuk namespace, tipe dan nama anggota. Jika ada akronim 2 huruf sebagai bagian dari nama, pertahankan huruf kapital bersama-sama, seperti IOStream.

Bagian 3.5 mencakup kelas penamaan, struct dan antarmuka.
Bagian 3.6 mencakup penamaan tipe anggota.
Bagian 3.7 mencakup parameter penamaan.


4
Maukah Anda meringkas bagi kita yang tidak memiliki buku itu?
Kramii Reinstate Monica

Saya setuju dengan Kramii. Ringkasan akan sangat bagus!
Vaccano

@ Kramil, Vaccano, Sepertinya aku harus memeriksanya dari perpustakaan lagi. Biasanya saya hanya melakukannya ketika memulai pekerjaan baru dan diskusi beralih ke standar penamaan dan pengkodean.
Tangurena

1
lol, jadi "Seseorang tidak dapat bergantung pada perbedaan dalam kasus saja untuk membedakan item", kemudian mengatakan menggunakan camelCase atau PascalCase untuk membedakan item.
gbjbaanb

1

Karena mereka dapat dibedakan karena tergantung pada konteks tempat mereka ditulis.

Misalnya, apakah Anda pernah menggunakan parameter sebagai variabel anggota? Atau variabel lokal sebagai parameter? Bagaimana dengan variabel anggota sebagai variabel lokal?

  • Semua variabel anggota berada di "tubuh" kelas. Saya benar-benar tidak membeli argumen yang Anda perlu awali anggota ketika Anda dapat menggunakannya thisuntuk membedakannya dari variabel lokal dengan nama yang mirip, kalau tidak, itu tidak diperlukan.

  • Variabel lokal juga hanya didefinisikan di dalam lingkup metode atau dalam lingkup blok kode.

  • Parameter selalu didefinisikan dalam tanda tangan metode.

Jika Anda membuat semua jenis variabel ini bingung atau tercampur bersama, maka Anda benar-benar harus lebih memikirkan desain kode Anda agar lebih mudah dibaca atau ditemukan. Beri mereka nama deskriptif yang lebih baik dan lebih mandiri daripada myInteger.


0

Saya tidak dapat menjawab pertanyaan Anda tentang standar Microsoft. Jika Anda ingin standar untuk membedakan hal-hal ini, standar yang saya gunakan untuk parameter PL / SQL adalah awalan nama parameter dengan in_, out_, io_, untuk parameter in, out, dan di-out. Variabel yang bersifat lokal ke suatu fungsi diawali dengan a v_.


0

Sebagian besar perusahaan yang saya kenal memiliki standar pengkodean yang menentukan baik garis bawah atau huruf kecil m (untuk "anggota" saya anggap) sebagai awalan untuk variabel anggota mereka.

Begitu

_varName

atau

mVarName


2
Ya, tetapi MS tidak lagi menggunakan m untuk anggota yang merupakan tujuan OP.
Christopher Bibbs

"Sebagian besar perusahaan" tidak termasuk Microsoft, yang merupakan perusahaan tempat pertanyaan ini membahas.
Aaronaught

1
Saya tidak menyadari bahwa Micrsoft MSDN adalah untuk standar pengkodean internal di Microsoft.
JeffO


0

Seperti yang telah ditunjukkan orang lain, Anda biasanya dapat mengetahui mana yang pada lingkup mana item tersebut digunakan. Anda sebenarnya tidak dapat memiliki parameter dan variabel lokal dalam cakupan yang sama dan jika Anda ingin variabel pribadi, cukup gunakan this.myInteger. Jadi saya tidak berpikir Microsoft terlalu khawatir tentang hal itu karena Anda dapat dengan mudah membedakan di antara mereka jika Anda mau.

Tapi itu dikatakan, saya sedikit terkejut bahwa belum ada yang mengatakan ini, tapi lupakan Microsoft dan konvensi penamaan mereka (mungkin seseorang sudah mengatakannya sekarang karena saya harus lari ke sebuah pertemuan dan membiarkannya terbuka tanpa mengajukan Itu). Notasi Hungaria juga merupakan konvensi penamaan yang dimulai di Microsoft (atau itu Xerox? Saya tidak pernah bisa mengingat kapan Simonyi datang dengan itu). Saya tidak bisa memikirkan siapa pun yang saya tahu yang tidak mengutuk nama notasi Hongaria hingga hari ini. Kami menjadi sangat terganggu dengan hal itu di tempat saya bekerja sehingga kami membuat standar kami sendiri yang kami gunakan secara internal. Itu lebih masuk akal bagi kami dan mempercepat pekerjaan kami (sebenarnya cukup dekat dengan apa yang disarankan Microsoft sekarang, tetapi semuanya merupakan kasus pascal dengan pengecualian variabel pribadi).

Yang sedang berkata, standar baru yang digunakan Microsoft (campuran camel case dan pascal case) tidak terlalu buruk. Tetapi jika Anda dan rekan kerja Anda tidak menyukainya, buatlah standar Anda sendiri (secara kolektif adalah yang terbaik). Ini tentu saja tergantung pada apakah perusahaan Anda sudah memiliki standar atau tidak. Jika ya, patuhi mereka. Kalau tidak datang dengan apa yang bekerja untuk Anda dan rekan kerja Anda. Tetap logis. '

Karena Aaronaught meminta kutipan tentang Charles Simonyi dan Notasi Hongaria: http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

Dua yang terakhir hanyalah contoh dari notasi Hongaria dan tautan ootips hanyalah beberapa kutipan mengenai beberapa pendapat tentang subjek tersebut. Perhatikan bahwa ada juga sistem Notasi Hongaria tetapi yang juga, sejauh yang saya ketahui, menjadi populer dari pemrogram Microsoft (meskipun tidak seperti Simonyi untuk variasi aplikasi, saya tidak tahu siapa).


1
1) Hongaria tidak ditemukan oleh Microsoft, dan 2) "Hungaria" yang Anda maksudkan adalah tipe Hungaria daripada Hungaria semantik.
Aaronaught

Saya tidak pernah mengatakan bahwa Microsoft datang dengan itu. Saya benar-benar mengatakan Charles Simonyi datang dengan itu (khusus aplikasi notasi hungaria). Microsoft sangat mendorongnya, tetapi saya tidak pernah mengatakan mereka membuatnya (sebenarnya saya bilang saya tidak yakin apakah dia membuatnya selama masa Xerox atau Microsoft-nya). Saya memberikannya sebagai contoh dari sesuatu yang disarankan oleh perusahaan besar (Microsoft) sebagai cara melakukan sesuatu. Maksud saya dalam semua ini adalah OP tidak perlu khawatir tentang penamaan konvensi bahwa perusahaan yang tidak bekerja untuknya mengatakan adalah "cara yang benar" (kecuali jika ia bekerja untuk Microsoft, dalam hal ini ia harus peduli).
JaCraig

[rujukan?]
Aaronaught

1
Um ya, kami tidak perlu kutipan tentang apa notasi Hongaria. [Kutipan diperlukan] untuk semua klaim yang meragukan dalam jawaban Anda.
Aaronaught
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.