Konvensi penamaan - garis bawah dalam variabel C ++ dan C #


146

Sangat umum untuk melihat _varnama variabel di bidang kelas. Apa arti garis bawah? Apakah ada referensi untuk semua konvensi penamaan khusus ini?



17
Beberapa pedoman pengkodean perusahaan yang salah menyarankan menambahkan kutil ke variabel anggota untuk membedakannya dari variabel lokal, karena keyakinan bahwa kelas dan fungsi akan tumbuh begitu besar sehingga Anda tidak dapat melacak apa yang tanpa petunjuk samar seperti ini. Orang-orang yang menyarankan konvensi semacam itu seringkali merupakan orang-orang yang kodenya paling membutuhkannya.
Mike Seymour

26
@ Mike - Pernyataan selimut Anda tidak benar. Saya telah menemukan bahwa menggunakan konvensi ini membuatnya lebih mudah untuk dengan cepat memindai metode dan mendapatkan pemahaman yang baik tentang kelas.
ChaosPandion

12
@ChaosPandion: maka jangan membacanya sebagai pernyataan selimut. "Beberapa" tidak berarti "semua", dan "terlalu sering" tidak berarti "selalu", dan mungkin Anda pengecualian untuk pengalaman saya.
Mike Seymour

17
Di C ++, hindari memimpin garis bawah. Dalam banyak konteks (yaitu, pada lingkup global, ketika huruf kapital mengikuti dll.) Dicadangkan untuk implementasi, dan Anda benar-benar mengambil risiko menginjak-injak makro. Jadi, jika Anda menginginkannya, buat mereka mengikuti garis bawah .
sbi

Jawaban:


120

Garis bawah hanyalah sebuah konvensi; tidak ada lagi. Dengan demikian, penggunaannya selalu agak berbeda untuk setiap orang. Inilah cara saya memahami mereka untuk dua bahasa yang dimaksud:

Dalam C ++, garis bawah biasanya menunjukkan variabel anggota pribadi.

Dalam C #, saya biasanya melihatnya hanya digunakan ketika mendefinisikan variabel anggota pribadi yang mendasari untuk properti publik. Variabel anggota pribadi lainnya tidak akan memiliki garis bawah. Penggunaan ini sebagian besar telah pergi ke pinggir jalan dengan munculnya sifat otomatis sekalipun.

Sebelum:

private string _name;
public string Name
{
    get { return this._name; }
    set { this._name = value; }
}

Setelah:

public string Name { get; set; }

11
Kecuali untuk tim yang ingin properti mereka tidak berubah.
ChaosPandion

11
Pengidentifikasi dimulai dengan garis bawah dicadangkan untuk kompiler. Menggunakan garis bawah awalan dapat bertentangan dengan simbol kompiler.
Thomas Matthews

12
@ Thomas Matthews - bukan dalam C #.
EMP

11
@ChaosPandion Saya berasumsi bahwa apa yang Anda maksud dengan "immutable" sebenarnya "read-only", dalam hal ini seseorang dapat menggunakan public string Name { get; private set; }. Benar, ini tidak sepenuhnya berubah, tetapi ada di sana.
jdmichal

7
@ Thomas dalam konteks kelas, pengidentifikasi dimulai dengan garis bawah diikuti dengan huruf kapital a dicadangkan di C ++. _vartidak dicadangkan.
Tyler McHenry

84

Ini adalah praktik terbaik untuk TIDAK menggunakan UNDERSCORES sebelum nama variabel atau nama parameter dalam C ++

Nama-nama yang dimulai dengan garis bawah atau garis bawah ganda DILINDUNGI untuk para pelaksana C ++. Nama dengan garis bawah dicadangkan agar perpustakaan berfungsi.

Jika Anda membaca di C ++ Coding Standard, Anda akan melihat bahwa di halaman pertama tertulis:

"Jangan terlalu banyak menyebutkan nama, tetapi gunakan konvensi penamaan yang konsisten: Hanya ada dua yang harus dilakukan: a) jangan pernah menggunakan" nama curang, "yang dimulai dengan garis bawah atau yang berisi garis bawah ganda;" (p2, Standar Penyandian C ++, Herb Sutter dan Andrei Alexandrescu)

Lebih khusus, draft kerja ISO menyatakan aturan aktual:

Selain itu, beberapa pengidentifikasi dicadangkan untuk digunakan oleh implementasi C ++ dan tidak boleh digunakan sebaliknya; tidak diperlukan diagnostik. (a) Setiap pengidentifikasi yang berisi garis bawah ganda __ atau dimulai dengan garis bawah diikuti dengan huruf besar disediakan untuk implementasi untuk penggunaan apa pun. (B) Setiap pengidentifikasi yang dimulai dengan garis bawah disediakan untuk implementasi untuk digunakan sebagai nama dalam namespace global.

Ini adalah praktik terbaik untuk menghindari memulai simbol dengan garis bawah jika Anda secara tidak sengaja berkeliaran di salah satu batasan di atas.

Anda bisa melihatnya sendiri mengapa penggunaan garis bawah seperti itu bisa menjadi bencana ketika mengembangkan perangkat lunak:

Coba kompilasi program helloWorld.cpp sederhana seperti ini:

g++ -E helloWorld.cpp

Anda akan melihat semua yang terjadi di latar belakang. Berikut ini cuplikannya:

   ios_base::iostate __err = ios_base::iostate(ios_base::goodbit);
   try
     {
       __streambuf_type* __sb = this->rdbuf();
       if (__sb)
  {
    if (__sb->pubsync() == -1)
      __err |= ios_base::badbit;
    else
      __ret = 0;
  }

Anda dapat melihat berapa banyak nama yang dimulai dengan garis bawah ganda!

Juga jika Anda melihat fungsi anggota virtual, Anda akan melihat bahwa * _vptr adalah pointer yang dihasilkan untuk tabel virtual yang secara otomatis akan dibuat ketika Anda menggunakan satu atau lebih fungsi anggota virtual di kelas Anda! Tapi itu cerita lain ...

Jika Anda menggunakan garis bawah, Anda mungkin mengalami masalah konflik dan Anda TIDAK AKAN MEMILIKI IDEA apa yang menyebabkannya, sampai semuanya terlambat.


4
Bukankah nama yang bukan global atau ruang lingkup file dan mulai dengan garis bawah dan huruf kecil baik-baik saja? Saya melakukan ini sepanjang waktu karena sangat bersih untuk kasus-kasus tertentu, misalnya: void A :: set_size (int _size) {size = _size; }. Apa yang Anda lakukan untuk penggunaan sepele seperti ini?
tukra

3
Garis bawah diikuti oleh huruf kecil diperbolehkan dalam lingkup non-global / file yang saya percaya. Bisakah Anda tunjukkan di mana dalam standar yang katanya bukan? Masalah dengan trailing garis bawah adalah saya sudah menggunakannya untuk anggota vars kadang-kadang. Jadi saya mungkin memiliki fungsi 'ukuran int ();' anggota var 'int size_;' dan argumen 'int _size'. Ini cenderung mencakup banyak hal dengan baik dan saya belum melihat alternatif yang lebih baik. Fungsi huruf kapital tidak dimungkinkan untuk obat generik yang bekerja dengan STL. Gaya 'this.size' yang disukai orang-orang C # cenderung rentan terhadap saya, kecuali jika Anda selalu menggunakannya untuk akses anggota yang jelek.
tukra

7
Saya mengerti beberapa orang yang tidak ingin menggunakan garis bawah dan huruf kecil karena mereka mungkin mengalami kesulitan menjaga apa yang legal. Standar C ++ memungkinkannya meskipun beberapa penulis merekomendasikan untuk tidak menggunakannya. Bagi saya, karena sepenuhnya legal dan tidak dilindungi undang-undang, saya tidak melihat alasan untuk menganggapnya berisiko. Terima kasih atas tanggapan Anda.
tukra

3
@tukra: Ini tidak sepenuhnya legal. Standar C ++ hanya memungkinkan Anda untuk menggunakan garis bawah tunggal diikuti oleh huruf kecil dalam lingkup lokal. Semoga berhasil! :-)
Constantinos Glynos

4
Maaf. Saya pikir kami dulu perlu mengulang kualifikasi. Identifikasi C ++ dimulai dengan garis bawah diikuti dengan huruf kecil diizinkan di setiap lingkup selain ruang lingkup file. Ini aman dan legal dalam fungsi, prototipe fungsi, kelas, struct, serikat, enum dan semua yang Anda masukkan ke dalam namespace. Jika Anda mengikuti praktik umum menempatkan semua kode Anda di ruang nama maka Anda benar-benar aman.
tukra

45

Sebenarnya _varkonvensi berasal dari VB bukan C # atau C ++ (m _, ... adalah hal lain).

Ini datang untuk mengatasi ketidakpekaan huruf VB ketika mendeklarasikan Properties.

Misalnya, kode seperti itu tidak dimungkinkan dalam VB karena menganggap userdan Usersebagai pengidentifikasi yang sama

Private user As String

Public Property User As String
  Get
    Return user
  End Get
  Set(ByVal Value As String)
    user = value
  End Set
End Property

Jadi untuk mengatasi ini, beberapa menggunakan konvensi untuk menambahkan '_' ke bidang pribadi untuk datang seperti ini

Private _user As String

Public Property User As String
  Get
    Return _user
  End Get
  Set(ByVal Value As String)
    _user = value
  End Set
End Property

Karena banyak konvensi untuk .Net dan untuk menjaga keseragaman antara konvensi C # et VB.NET, mereka menggunakan yang sama.

Saya menemukan referensi untuk apa yang saya katakan: http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices

Casing Unta dengan Garis Bawah Utama. Di VB.NET, selalu tunjukkan "Protected" atau "Private", jangan gunakan "Dim". Penggunaan "m_" tidak disarankan, seperti halnya penggunaan nama variabel yang berbeda dari properti dengan satu-satunya kasus, terutama dengan variabel yang dilindungi karena melanggar kepatuhan, dan akan membuat hidup Anda sakit jika Anda memprogram di VB.NET, saat Anda harus memberi nama anggota Anda sesuatu yang berbeda dari properti accessor / mutator. Dari semua item di sini, garis bawah utama adalah satu-satunya yang kontroversial. Saya pribadi lebih suka daripada unta garis bawah-lurus untuk variabel pribadi saya sehingga saya tidak harus memenuhi syarat nama variabel dengan "ini." untuk membedakan dari parameter dalam konstruktor atau tempat lain di mana saya kemungkinan akan memiliki tabrakan penamaan. Dengan VB.NET's case insensitivity, ini bahkan lebih penting karena properti accessor Anda biasanya akan memiliki nama yang sama dengan variabel anggota pribadi Anda kecuali untuk garis bawah. Sejauh m_, itu benar-benar hanya tentang estetika. Saya (dan banyak lainnya) menemukan m_ jelek, karena sepertinya ada lubang pada nama variabel. Hampir menyinggung. Saya dulu menggunakannya di VB6 sepanjang waktu, tapi itu hanya karena variabel tidak dapat memiliki garis bawah terkemuka. Saya tidak bisa lebih bahagia melihatnya hilang. Microsoft merekomendasikan terhadap m_ (dan straight _) meskipun mereka melakukan keduanya dalam kode mereka. Juga, awalan dengan tanda "m" lurus keluar. Tentu saja, karena mereka kode terutama dalam C #, mereka dapat memiliki anggota pribadi yang hanya berbeda dalam hal dari properti. Orang-orang VB harus melakukan sesuatu yang lain. Daripada mencoba dan menghasilkan kasus khusus bahasa demi bahasa, saya sarankan garis bawah utama untuk semua bahasa yang akan mendukungnya. Jika saya ingin kelas saya sepenuhnya CLS-compliant, saya bisa mengabaikan awalan pada variabel anggota C # yang dilindungi. Namun dalam praktiknya, saya tidak pernah khawatir tentang hal ini karena saya menjaga semua variabel anggota yang berpotensi dilindungi bersifat pribadi, dan sebagai gantinya menyediakan aksesor dan mutator yang dilindungi. Singkatnya, konvensi ini sederhana (satu karakter), mudah dibaca (mata Anda tidak terganggu oleh karakter terkemuka lainnya), dan berhasil menghindari penamaan tabrakan dengan variabel tingkat prosedur dan properti tingkat kelas.kelas properti tingkat . Saya merekomendasikan garis bawah utama untuk semua bahasa yang akan mendukungnya. Jika saya ingin kelas saya sepenuhnya CLS-compliant, saya bisa mengabaikan awalan pada variabel anggota C # yang dilindungi. Namun dalam praktiknya, saya tidak pernah khawatir tentang hal ini karena saya menjaga semua variabel anggota yang berpotensi dilindungi bersifat pribadi, dan sebagai gantinya menyediakan aksesor dan mutator yang dilindungi. Singkatnya, konvensi ini sederhana (satu karakter), mudah dibaca (mata Anda tidak terganggu oleh karakter terkemuka lainnya), dan berhasil menghindari penamaan tabrakan dengan variabel tingkat prosedur dan properti tingkat kelas.kelas properti tingkat . Saya merekomendasikan garis bawah utama untuk semua bahasa yang akan mendukungnya. Jika saya ingin kelas saya sepenuhnya CLS-compliant, saya bisa mengabaikan awalan pada variabel anggota C # yang dilindungi. Namun dalam praktiknya, saya tidak pernah khawatir tentang hal ini karena saya menjaga semua variabel anggota yang berpotensi dilindungi bersifat pribadi, dan sebagai gantinya menyediakan aksesor dan mutator yang dilindungi. Singkatnya, konvensi ini sederhana (satu karakter), mudah dibaca (mata Anda tidak terganggu oleh karakter terkemuka lainnya), dan berhasil menghindari penamaan tabrakan dengan variabel tingkat prosedur dan properti tingkat kelas.kelas properti tingkat . Saya tidak pernah khawatir tentang hal ini karena saya menjaga semua variabel anggota yang berpotensi dilindungi bersifat pribadi, dan sebaliknya menyediakan aksesor dan mutator yang dilindungi. Singkatnya, konvensi ini sederhana (satu karakter), mudah dibaca (mata Anda tidak terganggu oleh karakter terkemuka lainnya), dan berhasil menghindari penamaan tabrakan dengan variabel tingkat prosedur dan properti tingkat kelas.kelas properti tingkat . Saya tidak pernah khawatir tentang hal ini karena saya menjaga semua variabel anggota yang berpotensi dilindungi bersifat pribadi, dan sebaliknya menyediakan aksesor dan mutator yang dilindungi. Singkatnya, konvensi ini sederhana (satu karakter), mudah dibaca (mata Anda tidak terganggu oleh karakter terkemuka lainnya), dan berhasil menghindari penamaan tabrakan dengan variabel tingkat prosedur dan properti tingkat kelas.kelas properti tingkat .


6

Komentator pertama (R Samuel Klatchko) direferensikan: Apa aturan tentang menggunakan garis bawah dalam pengidentifikasi C ++? yang menjawab pertanyaan tentang garis bawah di C ++. Secara umum, Anda tidak seharusnya menggunakan garis bawah utama, karena disediakan untuk pelaksana kompiler Anda. Kode yang Anda lihat _varmungkin adalah kode lama, atau kode yang ditulis oleh seseorang yang tumbuh menggunakan sistem penamaan lama yang tidak disukai pemimpin garis bawah.

Sebagai jawaban lain menyatakan, ini digunakan untuk digunakan dalam C + + untuk mengidentifikasi variabel anggota kelas. Namun, tidak memiliki arti khusus sejauh dekorator atau sintaks berjalan. Jadi jika Anda ingin menggunakannya, itu akan dikompilasi.

Saya akan menyerahkan diskusi C # kepada orang lain.


5

_var tidak memiliki arti dan hanya melayani tujuan untuk membuatnya lebih mudah untuk membedakan bahwa variabel tersebut adalah variabel anggota pribadi.

Dalam C ++, menggunakan konvensi _var adalah bentuk yang buruk, karena ada aturan yang mengatur penggunaan garis bawah di depan pengidentifikasi. _var dicadangkan sebagai pengidentifikasi global, sedangkan _Var (garis bawah + huruf kapital) dicadangkan kapan saja. Inilah sebabnya mengapa di C ++, Anda akan melihat orang yang menggunakan konvensi var_ sebagai gantinya.


4

Anda dapat membuat pedoman pengkodean Anda sendiri. Cukup tulis dokumentasi yang jelas untuk anggota tim lainnya.

Menggunakan _field membantu Intelilsense untuk memfilter semua variabel kelas cukup mengetik _.

Saya biasanya mengikuti Pedoman Brad Adams , tetapi disarankan untuk tidak menggunakan garis bawah.


2

Microsoft penamaan standar untuk C # kata variabel dan parameter harus menggunakan bentuk kasus unta lebih rendah IE: paramName . Standar ini juga menyerukan bidang untuk mengikuti bentuk yang sama tetapi hal ini dapat menyebabkan kode tidak jelas sehingga banyak tim panggilan untuk awalan garis bawah untuk meningkatkan kejelasan IE: _fieldName .


2

Dengan C #, Pedoman Desain Kerangka Microsoft menyarankan untuk tidak menggunakan karakter garis bawah untuk anggota publik . Untuk anggota pribadi , garis bawah tidak masalah untuk digunakan. Bahkan, Jeffrey Richter (sering dikutip dalam pedoman) menggunakan m_ misalnya dan "s_" untuk anggota statis pribadi.

Secara pribadi, saya menggunakan _ hanya untuk menandai anggota pribadi saya. "m_" dan "s_" ambang pada notasi Hungaria yang tidak hanya disukai di .NET, tetapi bisa sangat verbose dan saya menemukan kelas dengan banyak anggota sulit untuk melakukan pemindaian mata cepat secara alfabet (bayangkan 10 variabel semua dimulai dengan m_) .


Karena notasi Hongaria menunjukkan tipe, saya tidak berpikir Anda benar-benar dapat mengatakan bahwa m / s ambang di atasnya.
Jerry Nixon

@ JerryNixon-MSFT Apakah kita mengidentifikasi tipe data variabel dan tipe visibilitas variabel sebagai hal yang sama dalam hal pengertian Hongaria?
Necro

1

Saya menggunakan penamaan _var untuk variabel anggota kelas saya. Ada 2 alasan utama yang saya lakukan:

1) Ini membantu saya melacak variabel kelas dan variabel fungsi lokal ketika saya membaca kode saya nanti.

2) Ini membantu dalam Intellisense (atau sistem penyelesaian kode lainnya) ketika saya sedang mencari variabel kelas. Mengetahui karakter pertama sangat membantu dalam memfilter daftar variabel dan metode yang tersedia.


1
Ini adalah kerumitan dalam metode yang lebih besar untuk mengandalkan melayang intellisense atau pemindaian untuk melihat apakah var didefinisikan secara lokal atau tidak. Juga lebih suka "__" untuk statika untuk alasan yang sama yang Anda sebutkan tetapi saat ini tidak disukai.
crokusek

1

Sejauh menyangkut bahasa C dan C ++, tidak ada arti khusus untuk garis bawah pada nama (awal, tengah atau akhir). Itu hanya karakter nama variabel yang valid. "Konvensi" berasal dari praktik pengkodean dalam komunitas pengkodean.

Seperti yang telah ditunjukkan oleh berbagai contoh di atas, _ pada awalnya dapat berarti anggota kelas yang pribadi atau dilindungi dalam C ++.

Biarkan saya memberikan sedikit sejarah yang mungkin menyenangkan. Di UNIX jika Anda memiliki fungsi pustaka inti C dan kernel back-end di mana Anda ingin mengekspos fungsi kernel ke ruang pengguna juga _ terjebak di depan fungsi stub yang memanggil fungsi kernel secara langsung tanpa melakukan hal lain. Contoh yang paling terkenal dan dikenal adalah exit () vs _exit () di bawah kernel tipe BSD dan SysV: Di sana, exit () melakukan hal-hal ruang-pengguna sebelum memanggil layanan keluar kernel, sedangkan _exit hanya memetakan ke layanan keluar kernel.

Jadi _ digunakan untuk barang-barang "lokal" dalam hal ini lokal menjadi mesin-lokal. Biasanya _functions () tidak portabel. Karena itu Anda seharusnya tidak mengharapkan perilaku yang sama di berbagai platform.

Sekarang untuk _ dalam nama variabel, seperti

int _foo;

Nah secara psikologis, _ adalah hal yang aneh harus mengetik di awal. Jadi jika Anda ingin membuat nama variabel yang memiliki peluang lebih kecil untuk berbenturan dengan sesuatu yang lain, TERUTAMA saat berurusan dengan penggantian pra-prosesor yang ingin Anda pertimbangkan penggunaan _.

Saran dasar saya adalah untuk selalu mengikuti konvensi komunitas pengkodean Anda, sehingga Anda dapat berkolaborasi secara lebih efektif.


0

Ini berarti bahwa itu adalah bidang anggota di kelas.


0

Tidak ada konvensi penamaan tunggal, tetapi saya telah melihatnya untuk anggota pribadi.


0

Banyak orang suka bidang pribadi diawali dengan garis bawah. Itu hanya konvensi penamaan.

Konvensi penamaan 'resmi' C # menentukan nama huruf kecil sederhana (tanpa garis bawah) untuk bidang pribadi.

Saya tidak mengetahui konvensi standar untuk C ++, meskipun garis bawah sangat banyak digunakan.


0

Ini hanya sebuah konvensi yang digunakan oleh beberapa programmer untuk memperjelas ketika Anda memanipulasi anggota kelas atau beberapa jenis variabel lainnya (parameter, lokal ke fungsi, dll). Konvensi lain yang juga digunakan secara luas untuk variabel anggota adalah awalan nama dengan 'm_'.

Bagaimanapun, ini hanya konvensi dan Anda tidak akan menemukan satu sumber pun untuk semuanya. Mereka masalah gaya dan masing-masing tim pemrograman, proyek atau perusahaan memiliki sendiri (atau bahkan tidak punya).


0

Ada alasan yang sepenuhnya sah untuk menggunakannya dalam C #: jika kode juga dapat diperluas dari VB.NET. (Kalau tidak, aku tidak akan.)

Karena VB.NET tidak peka huruf besar-kecil, tidak ada cara mudah untuk mengakses fieldanggota yang dilindungi dalam kode ini:

public class CSharpClass
{
    protected int field;
    public int Field { get { return field; } }
}

Misalnya ini akan mengakses pengambil properti, bukan bidang:

Public Class VBClass
    Inherits CSharpClass

    Function Test() As Integer
        Return Field
    End Function

End Class

Heck, saya bahkan tidak bisa menulis fielddalam huruf kecil - VS 2010 terus memperbaikinya.

Agar mudah diakses oleh kelas turunan di VB.NET, kita harus membuat konvensi penamaan yang lain. Mengawali garis bawah mungkin adalah yang paling tidak mengganggu dan paling "diterima secara historis" dari mereka.


0

Sekarang notasi menggunakan "ini" seperti dalam this.foobarbaz dapat diterima untuk variabel anggota kelas C #. Ini menggantikan notasi "m_" lama atau hanya "__". Itu membuat kode lebih mudah dibaca karena tidak ada keraguan apa yang sedang referensi.


0

Dari pengalaman saya (tentu terbatas), garis bawah akan menunjukkan bahwa itu adalah variabel anggota pribadi. Seperti yang dikatakan Gollum, ini akan tergantung pada tim.


0

Pertanyaan lama, jawaban baru (C #).

Penggunaan lain dari garis bawah untuk C # adalah dengan ASP NET Core (ketergantungan injeksi). readonlyVariabel pribadi dari kelas yang ditugaskan ke antarmuka yang disuntikkan selama konstruksi harus dimulai dengan garis bawah. Saya kira ini adalah perdebatan apakah akan menggunakan garis bawah untuk setiap anggota kelas (walaupun Microsoft sendiri mengikutinya) tetapi yang ini pasti.

private readonly ILogger<MyDependency> _logger;

public MyDependency(ILogger<MyDependency> logger)
{
    _logger = logger;
}

-2

Konvensi penamaan seperti ini berguna ketika Anda membaca kode, terutama kode yang bukan milik Anda. Konvensi penamaan yang kuat membantu menunjukkan di mana anggota tertentu didefinisikan, apa jenis anggotanya, dll. Sebagian besar tim pengembangan mengadopsi konvensi penamaan yang sederhana, dan hanya awalan bidang anggota dengan garis bawah ( _fieldName). Di masa lalu, saya telah menggunakan konvensi penamaan berikut untuk C # (yang didasarkan pada konvensi Microsoft untuk .NET framework code, yang dapat dilihat dengan Reflector):

Bidang Instans: m_fieldName
Bidang Statis: s_fieldName
Publik / Dilindungi / Anggota Internal: PascalCasedName ()
Anggota Pribadi: camelCasedName ()

Ini membantu orang memahami struktur, penggunaan, aksesibilitas, dan lokasi anggota saat membaca kode asing dengan sangat cepat.


3
Sebenarnya, Microsoft tidak menyarankan untuk menggunakan awalan m_, s_. Jangan gunakan awalan untuk nama bidang. Misalnya, jangan gunakan g_ atau s_ untuk membedakan bidang statis versus non-statis. msdn.microsoft.com/en-us/library/ms229012.aspx
Zied

1
Seperti yang saya katakan, lihat kode sumber mereka dengan Reflector. Anda akan terkejut betapa mereka mengabaikan rekomendasi mereka sendiri. ;) Seperti yang disebutkan oleh pos saya, ini membantu meningkatkan keterbacaan kode Anda, dan tim terakhir saya sangat menyukai konvensi penamaan yang tercantum di atas.
jrista
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.