Bagaimana Anda memberi nama variabel pribadi Anda di C #? [Tutup]


25

Apa praktik terbaik, konvensi penamaan yang paling umum diterima untuk variabel pribadi dalam C #?

  1. private int myInteger;
  2. private int MyInteger;
  3. private int mMyInteger;
  4. private int _myInteger;
  5. private int _MyInteger;
  6. Opsi misterius lainnya

Yang mana yang Anda gunakan dan mengapa? (Perusahaan saya cukup baru di C # dan saya ingin memilih metode "yang paling diterima industri" untuk mencoba dan masuk ke standar pengkodean kami.)


Mengapa tidak menggunakan Properti yang Diimplementasikan Otomatis? msdn.microsoft.com/en-us/library/bb384054.aspx
Kyle Ballard

1
C # memiliki standar untuk ini, lihat stackoverflow.com/questions/14967/…
Tamara Wijsman

7
Tidak baik berbicara tentang variabel pribadi di depan umum. Maaf, baru saja harus.
Mark C

Saya menggunakan yang sama dengan azheglov (m_someVariable) dengan pengecualian saya hanya menggunakan _someVariable dalam lingkup lokal ke suatu metode.
Tuan-fu

7
@ Mark saya pikir itu harus "anggota pribadi" untuk menjadi sugestif.
EpsilonVector

Jawaban:


44

Pedoman desain kelas MSDN http://msdn.microsoft.com/en-us/library/ta31s3bc.aspx merekomendasikan opsi 1 - myInteger.

Saya selalu menggunakan gaya ini. Saya memiliki ketidaksukaan pribadi terhadap karakter _.


1
Saya tidak menyukai karakter _ sampai resharper menambahkan mid string yang cocok dengan intellisence. Sekarang saya bisa mengetik myIntegerdan akan cocok _myInteger. Tetapi saya tidak tahu bahwa MSDS mengatakan untuk tidak menggunakan _
Vaccano

4
Jika Anda menggunakan opsi 1, bagaimana saya bisa tahu apakah myIntegervariabel lokal ke metode, atau anggota kelas pribadi?
Wizard79

4
@Lorenzo this.myInteger;)
TWith2Sugars

12
Tapi ... "ini" adalah 4 karakter dan "_" hanya satu! Sebenarnya, pedoman itu sangat masuk akal, tetapi di kantor saya semua orang suka menggarisbawahi dan benci melihat "this.Foo", untuk alasan apa pun. Terkadang satu-satunya pedoman yang penting adalah yang dipaksakan oleh tempat kerja Anda pada Anda.
CodexArcanum

2
Argumen tentang jumlah karakter masih bisa diperdebatkan. Anda tidak perlu mengetik thissetiap waktu, hanya dalam metode di mana variabel lokal dengan nama yang sama hadir. Namun, Anda diharuskan untuk menulis simbol tambahan setiap kali jika Anda menggunakan garis bawah. Dengan apa yang saya setujui adalah bahwa berpegang teguh pada perjanjian gaya kode lokal Anda selalu penting.
Malcolm

25

Saya menggunakan opsi # 4 di atas:

private int _myInteger;

Saya suka memiliki beberapa indikasi cakupan dalam nama variabel saya, dan garis bawah cukup untuk tujuan itu. Ini juga cukup mudah dibaca.


5
Saya tidak setuju bahwa itu mudah dibaca, terutama jika Anda harus beroperasi dengan beberapa variabel.
Restuta

15

Saya menggunakan skema penamaan berikut:

  • 1st (myInteger) untuk variabel cakupan lokal
  • 2nd (MyInteger) untuk properti publik
  • 4th (_myInteger) untuk variabel pribadi

14

Saya pikir opsi 4 adalah opsi yang paling mudah dibaca. Ini membantu Anda dari keharusan melakukan ini:

public Person(string name, int age) 
{
    this.name = name;
    this.age = age;
}

Itu juga membuat semua anggota pribadi lebih terlihat. Pada contoh berikut, dari mana agedatangnya? Tanpa thiskualifikasi, sulit untuk mengatakannya.

private void Method()
{
    var x = 2;
    var y = age + x;
}

Ini cara yang lebih mudah untuk dipahami:

private void Method()
{
    var x = 2;
    var y = _age + x;
}

1
Saya dulu bersumpah dengan contoh pertama Anda, tetapi setelah mencoba opsi # 4 untuk sementara waktu saya lebih suka menggunakan garis bawah sebagai awalan untuk bidang pribadi.
Jeremy Wiebe

2
Saya katakan, gunakan 1 untuk variabel pribadi, gunakan 4 untuk variabel pribadi yang digunakan dalam properti.
Evan Plaice

2
Saya harus tidak setuju dengan ChaosPandoin. Bagi saya, kedua implementasi Metode () mudah dibaca. Segera setelah saya melihat variabel umur (atau _age) dan perhatikan bahwa itu tidak dideklarasikan dalam metode, saya menyadari itu harus dideklarasikan di tempat lain di kelas. Kualifikasi ini buruk tetapi setidaknya terbatas pada metode konstruktor.
David Kennedy

10

Pertama, PascalCasing biasanya disediakan untuk properti publik, const, metode, dll dari kelas. Jadi saya akan melewati 2 dan 5.

Kedua, notasi Hungaria tidak disarankan di dunia .NET, jadi (eh, saya pikir) 3 benar. Dengan asumsi itulah yang terjadi dengan 3.

Yang tersisa dengan camelCasing dan _camelCasing. Saya biasanya menggunakan _camelCasing untuk variabel kelas, dan camelCasing tua biasa untuk variabel yang dicakup dalam suatu metode atau lebih sempit. Casing unta adalah standar yang diterima yang digunakan untuk argumen metode, nama variabel yang dilindungi / pribadi dan variabel dalam metode atau cakupan yang lebih sempit.

Saya juga suka menambahkan dengan garis bawah sehingga variabel pribadi saya dikelompokkan dalam intellisense saya. Namun, saya hanya melakukan ini untuk variabel yang mencakup satu jenis. Variabel yang dideklarasikan dalam metode atau lingkup yang lebih sempit saya biarkan garis bawah mati. Mempermudah pemisahan dan menjaga variabel yang jarang digunakan bersama.


2
Saya tidak mengerti mengapa Anda akan menggunakan _camelCasing untuk variabel kelas, karena biasanya jelas bahwa mereka adalah variabel kelas.
alternatif

1
@ tidak, itu tidak jelas di intellisense. Ingat, bidang (variabel cakupan kelas) memiliki (hampir) ikon yang sama dengan variabel cakupan metode, sehingga tampilannya persis sama jika Anda tidak melihat dengan cermat. Garis bawah membantu membedakannya secara visual dan membuat mereka dikelompokkan bersama, yang membantu jika Anda tidak sering menggunakannya (yang seharusnya tidak menjadi musuh pemrograman bebas bug).
Ripped Off

Saya tidak pernah mengatakan apapun tentang Intellisense. Saya berbicara tentang perbedaan antara Color.ClassMethod () dan myColor.InstanceMethod (), yaitu harus jelas bahwa karena Warna adalah kelas, ClassMethod () adalah metode kelas.
alternatif

@math you before: I don't understand why you would use _camelCasing for class variables you after: I'm talking about the difference between Color.ClassMethod() and myColor.InstanceMethod()Maafkan saya saat saya bingung. Dengar, saya jarang menggunakan variabel kelas, jadi senang diingatkan akan nama mereka dengan menekan _ dan meminta mereka semua muncul dalam intellisense yang bagus dan dikelompokkan.
Ripped Off

2
@ mathepic: When Will mengatakan "variabel kelas" yang ia maksud adalah bidang instance (pribadi). Anda tampaknya telah menafsirkan apa yang dikatakannya sebagai anggota statis; tapi bukan itu yang dia katakan.
Dan Tao

4

private int integer

Jika Anda bingung antara variabel anggota dan lokal dalam ruang lingkup metode maka Anda mungkin perlu refactor.


+1: itulah yang saya yakini intinya. BTW: Saya melihat sumbernya, tetapi namanya integerbisa ditulis ulang dengan lebih baik, mungkin value?
Wolf

2

Saya percaya cara terbaik untuk melakukannya (dalam C # /. Net) adalah kombinasi dari 2 dan 6:

private int MyInteger { get; set; }

Secara teori tidak ada variabel sama sekali di sini, tetapi terlihat dan bertindak seperti variabel instance pribadi. Jika kita perlu menambahkan beberapa logika bisnis ke nilai itu (ini adalah nilai yang sepenuhnya internal, jadi kita bisa melakukan apa pun yang kita inginkan darinya) maka itu sudah 'milik' untuk kita. Secangkir menang panas yang mengepul!


2

Saya melakukan opsi # 4 karena seperti itulah tampilan SSCLI, tapi jujur ​​saya tidak terlalu peduli pada penamaan variabel pribadi. Publik adalah cerita yang berbeda.

BTW Anda lupa m_MyInteger


2

Aku tidak akan menyebutnya apa pun "milikku"!

Tapi saya akan katakan

class C
{
     int VariableName { get; set; }
}

cukup sering ini lebih baik daripada memiliki variabel eksplisit. Jika saya memiliki variabel pribadi yang eksplisit saya akan menyebutnyaint _variableName;


1

Dalam C ++ saya cenderung menggunakan _ karena saya sering mengganti editor yang tidak memungkinkan saya untuk melihat apakah itu pribadi.

Untuk C # saya cenderung meninggalkan _ pergi karena Visual Studio memungkinkan saya untuk melihat apakah itu pribadi.

Saya cenderung menggunakan cara Unta untuk melakukan ini.


1

Saya menggunakan 4 ( private int _myInteger;) karena:

private int myInteger;

Ini adalah bagaimana saya memberi nama variabel lokal saya.

private int MyInteger;

Ini adalah bagaimana saya menyebutkan konstanta.

private int mMyInteger;

Ini bukan gaya C #.

private int _MyInteger;

Ini terlihat aneh.


1

dengan garis bawah.

Bill Wagner menjelaskan alasannya dalam Efektif C # . Tapi aku tidak pernah akan nama integer saya Integer , lebih baik seperti _age atau _length. Memasukkan TypeName dalam nama instance adalah praktik yang mengerikan. Nama harus jelas dan karena C # adalah Tipe-Jenis Aman dapat ditemukan sepanjang waktu.


1
Ya, itu adalah contohnya.
Vaccano

1

Anda perlu memberikan contoh yang lebih spesifik, tetapi:

private int count, private int badFileCount,private static readonly int ReconnectAttemptsLimit

Omong-omong, Anda mendapatkan semua ini GRATIS ketika Anda menginstal dan mulai menggunakan yang terbaru dan terbaik MSFT Stylecop.


0

Saya memilih opsi 5: private int _MyFoo

Saya tidak melihat keunggulan kompetitif nyata di atas _myFoo.


0

Gunakan camelCasing untuk variabel pribadi seperti myInteger

Pertimbangkan sebelumnya _jika variabel adalah cadangan untuk properti untuk mengurangi kebingungan-
Variabel _myPropertyuntuk propertiMyProperty


0

Saya memiliki nama ReSharper variabel saya, tidak hanya milik saya tetapi semua orang melakukan ini juga. Ada sejumlah besar konsistensi melalui proyek.


0

IDesign C # Coding Standar Juval Lowy cukup populer. Standar ini merekomendasikan awalan variabel anggota pribadi dengan "m_" (Opsi 6). Itu yang kami lakukan di tim kami.

private int m_myInteger;

Opsi 4 ( _myInteger) adalah variasi yang dapat diterima dari standar ini.

Saya tidak suka rekomendasi MSDN ( myInteger), karena membuatnya sulit untuk memberi tahu anggota pribadi dari variabel lokal. Rekomendasi mereka, tentu saja, menyelesaikan masalah ini dengan anggota swasta yang memenuhi syarat this, yang tampaknya berlebihan bagi saya.

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.