Konvensi penamaan variabel? [Tutup]

11

Saya baru saja mulai menggunakan ReSharper (untuk C #) dan saya agak suka dengan kode baunya finder, itu menunjukkan kepada saya beberapa hal tentang tulisan saya yang ingin saya perbaiki sejak lama (terutama konvensi penamaan variabel).

Itu membuat saya mempertimbangkan kembali beberapa konvensi penamaan saya untuk metode dan variabel instan. ReSharper menyarankan bahwa variabel instance menjadi case unta yang lebih rendah dan mulai dengan garis bawah. Untuk sementara saya bermaksud membuat semua variabel lokal saya lebih rendah dari unta tetapi apakah garis bawah itu diperlukan? Apakah Anda merasa nyaman? Saya tidak suka konvensi ini tetapi saya juga belum mencobanya, apa pendapat Anda tentang itu?

Hal kedua yang mendorong saya untuk mengevaluasi kembali adalah konvensi penamaan saya untuk event handler GUI. Saya biasanya menggunakan standar VS dari ControlName_Action dan kontrol saya biasanya menggunakan notasi hungaria (sebagai akhiran, untuk membantu memperjelas dalam kode apa yang terlihat oleh pengguna dan apa yang tidak ketika berurusan dengan variabel dengan nama yang sama) jadi saya berakhir dengan OK_btn_Click ( ), apa pendapat Anda tentang itu? Haruskah saya menyerah pada konvensi ReSharper atau ada opsi lain yang sama validnya?

c# naming resharper

— Ziv
sumber

19

Anda dapat memodifikasi ReSharper untuk menggunakan skema konvensi penamaan mana pun yang Anda gunakan. Ini cukup fleksibel, termasuk menyesuaikan event handler, bidang, properti, metode dengan berbagai tingkat aksesibilitas dll.

Jangan biarkan alat mendefinisikan standar Anda - gunakan untuk menegakkan standar Anda.

Pembaruan: Karena itu, di tempat kerja kami menggunakan kasus unta yang lebih rendah untuk sebagian besar hal pribadi - variabel, bidang, dan argumen. Casing unta atas untuk nama metode, konstanta, dan properti. Penangan acara diberi nama berdasarkan pada tindakan yang mereka wakili, alih-alih sesuatu yang spesifik untuk kontrol - misalnya HandleCustomerContinue daripada HandleContinueButtonClick. Saya mencoba skema default ReSharper untuk sementara waktu dan sebenarnya tidak keberatan, saya benar-benar tidak rewel.

— mjhilton
sumber

Tentu saja, saya sangat suka bagaimana ini membantu saya menjaga variabel lokal saya di cek tapi saya ingin tahu tentang standar orang lain, terutama ketika datang ke event handler.

— Ziv

Cukup adil, saya telah diedit untuk memberikan detail pengalaman pribadi yang lebih banyak.

— mjhilton

11

+1 untuk "Jangan biarkan alat menentukan standar Anda"

— techie007

"Jangan biarkan alat mendefinisikan standar Anda" baru saja menjadi salah satu kutipan pemrograman favorit saya sepanjang masa.

— Seggy

18

Dengan hormat

tetapi apakah garis bawah itu perlu? apakah kamu merasa nyaman?

Satu hal yang saya suka banyak tentang menggunakan garis bawah, adalah secara dramatis mengurangi penggunaan "ini".

Mempertimbangkan:

public void Invoke(int size) {
    _size = size;
}

tanpa garis bawah, Anda harus menulis:

public void Invoke(int size) {
    this.size = size;
}

yang berpotensi menyebabkan kesalahan halus:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

Selain itu, penyelesaian kode lebih bersih karena hanya dengan mengikat garis bawah Anda mendapatkan daftar hanya bidang pribadi, sedangkan dengan "ini" Anda mendapatkan daftar semuanya.

Dengan hormat

biasanya menggunakan notasi Hungaria

Pedoman Kerangka Kerja Desain: Konvensi, Idoms, dan Pola untuk Reusable .NET libraries mengatakan:

JANGAN gunakan notasi Hongaria

Meninggalkan sedikit ruang untuk ambiguitas :)

— Dakotah Utara
sumber

Sebenarnya, jika Anda mengikuti Kerangka Desain Pedoman, ini menyatakan bahwa variabel yang dilewatkan ke metode publik juga harus dalam huruf kapital, di samping nama metode :)

— Coder Bedah

pzycoman ... bisakah Anda mengarahkan saya ke tempat dinyatakannya. Pandangan cepat dan saya tidak dapat menemukan referensi untuk menggunakan huruf kapital dalam variabel yang diteruskan ke metode publik. Tetapi misalnya, pada P 118 edisi kedua, ada contoh di mana metode publik tidak menggunakan huruf besar tetapi huruf kecil. "public void Write (nilai tidak);"

— Dakotah North

10

Dalam kasus bentrokan nama saya akan mengatakan itu this.sizejauh lebih jelas daripada _size. Menggunakan nama yang digarisbawahi tidak mencegah kesalahan halus, Anda masih dapat menetapkan ukuran untuk dirinya sendiri, meskipun mudah-mudahan kompiler Anda akan memberi tahu Anda.

— edA-qa mort-ora-y

2

Tentu, Anda selalu dapat menetapkan sesuatu untuk dirinya sendiri. Perbedaan utama antara this.sizedan _sizekonsistensi. Dengan this.sizeitu adalah opsional. Misalnya, jika ada bidang pribadi lain yang disebut name, tidak perlu digunakan this.namedalam kode, saya bisa dengan mudah menggunakan nametanpa bentrokan. Karena thisterkadang bisa digunakan, dan tidak kali lain mengapa menggunakan thislebih rendah. Di sisi lain, tidak ada ambiguitas dengan _...

— Dakotah Utara

2

Ugh ... kenapa orang masih menggunakan garis bawah dalam bahasa yang menyediakan cara yang lebih baik.

— Rig

8

Konsistensi adalah kuncinya. Itu dan kejelasan, yaitu jangan samar atau mencoba menyimpan mengetik dengan menyingkat semuanya. Intellisense adalah pengetik pengetik Anda, bukan nama samar (tetapi singkat!).

— richard
sumber

2

+1: Pilih satu konvensi dan patuhi itu. Apa pun akan dilakukan (kecuali Sistem Hungaria).

— Donal Fellows

Konsistensi bukanlah satu-satunya hal. Misalnya, seseorang dapat memilih konvensi penamaan yang konsisten untuk kode mereka sendiri, tetapi jika konvensi itu sangat berbeda dari konvensi penamaan lainnya, maka ketika menggunakan perpustakaan lain ... pasti akan ada inkonsistensi. Misalnya, jika saya memilih untuk menggunakan konvensi penamaan properti dari C # di Java, saya tidak akan konsisten dengan bagaimana kode ditulis di semua sistem lain. Saya dapat menulis order.Size()(sebagai lawan dari order.getSize()) tetapi karena perpustakaan lain menggunakan getter dan setter kode saya tidak akan konsisten.

— Dakotah North

Tentunya harus ada pemikiran cerdas di balik konvensi apa pun yang seseorang memutuskan untuk digunakan, tetapi konsistensi adalah hal yang paling penting.

— richard

@DakotahNorth - masuk akal untuk memiliki gaya rumah, tetapi lebih dari itu, konsistensi adalah pertimbangan utama. Selama konvensi ini tidak terlalu rumit, ia dapat dengan mudah diambil oleh pengembang eksternal / baru. Memang, ada baiknya menerbitkan gaya rumah, untuk menghilangkan ketidakpastian.

— cjmUK

7

Di C # mulai dilindungi atau nama publik dengan garis bawah bertentangan dengan Spesifikasi Bahasa Umum. Itu hanya benar jika anggota pribadi.

Dari MSDN:

Untuk sepenuhnya berinteraksi dengan objek lain terlepas dari bahasa tempat mereka diimplementasikan, objek harus mengekspos ke penelepon hanya fitur-fitur yang umum untuk semua bahasa yang harus mereka interoperasikan. Untuk alasan ini, Spesifikasi Bahasa Umum (CLS), yang merupakan serangkaian fitur bahasa dasar yang dibutuhkan oleh banyak aplikasi, telah ditentukan.

Lihat: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Di sini Anda dapat membaca peringatan tentang garis bawah:

Nama elemen yang dimulai dengan garis bawah (_) bukan bagian dari Spesifikasi Bahasa Umum (CLS), jadi kode yang sesuai dengan CLS tidak dapat menggunakan komponen yang mendefinisikan nama-nama tersebut. Namun, garis bawah pada posisi lain apa pun dalam nama elemen adalah CLS-compliant.

Lihat: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Anggota yang dilindungi adalah masalah karena Anda dapat mewarisi dari kelas yang ditulis dalam bahasa lain.

Tapi mungkin itu bukan masalah dalam kasus Anda jika Anda tidak memerlukan kode kompilasi CLS.

— psur
sumber

4

Saya suka garis bawah. Anda tahu sekilas bahwa variabel adalah anggota kelas dan pribadi.

Tentu IDE dapat memberitahu Anda bahwa ketika Anda mengarahkan mouse di atasnya, tetapi "pandangan pertama" tidak dapat dikalahkan. Anda tahu apa variabel lokal, dan apa variabel anggota dengan mata Anda sendiri. Tidak perlu menggulir atau menggulir mouse.

Anda dapat menggunakan kata kunci "ini" tetapi _ lebih pendek untuk pemindaian horizontal yang lebih baik. Nama deskriptif biasanya diinginkan tetapi ketika sesuatu merupakan konvensi yang mapan, lebih baik memiliki 1 karakter. misalnya menggunakan huruf i sebagai indeks saat perulangan melalui array. Karena ini adalah konvensi mapan bahwa saya adalah indeks, Anda mendapatkan manfaat pemindaian tanpa kelemahan bertanya-tanya apa arti "i".

— mike30
sumber

1

Saya setuju secara umum dengan apa yang dikatakan oleh orang lain, tetapi ketika datang ke alat dan rantai alat, saya malas dan seperti kehidupan yang mudah. Saya menemukan hidup sering lebih mudah untuk melakukannya seperti yang mereka sarankan. Alasannya adalah

Lebih mudah untuk menginstal (cukup dengan default, bahkan saya dapat menekan Enter 20 kali dan menjalankannya)
Bug biasanya telah dikerjakan dari pengaturan default, seringkali dengan konfigurasi esoterik yang saya atur yang memperlihatkan cacat untuk pertama kalinya
Penjual rantai alat mungkin tahu lebih banyak tentang hal itu daripada saya, karena itu mereka membuatnya seperti itu karena suatu alasan. Siapa saya yang memutuskan para ahli itu salah (saya menganggap mereka ahli, karena saya membeli alat mereka)
Anda tidak akan pernah harus mempertahankan pilihan vendor oleh Manajer - "Itu yang Mereka rekomendasikan"
Lelaki baru tidak akan mengganggumu dengan "mengapa" dan "Lebih baik begitu" - Ketika setiap jawaban adalah "karena Mereka memutuskan ..."

Jadi pendapat saya adalah jika Anda dapat menemukan alasan yang sah untuk mengkonfigurasi ulang alat yang baru saja Anda habiskan, dengan segala cara melakukannya. Jika Anda tidak dapat membenarkan untuk melakukan perubahan, jangan lakukan.

Perlu diingat bahwa setiap perubahan memiliki biaya berkelanjutan (nyata dan tersembunyi) untuk dipertahankan. Semakin sedikit, semakin rendah biaya. Misalnya - orang baru yang saya sebutkan - tidak ada perubahan berarti dia bisa membaca manual mereka. Konfigurasi ulang - Anda harus menulis adendum, menyimpannya dengan barang-barang lainnya, mengundurkannya, dan membuatnya membacanya setelah membaca manual mereka. Mungkin bukan masalah untuk toko 2 orang, tapi bagaimana dengan toko 100 orang?

— mattnz
sumber

1

Dua aturan yang Anda tanyakan, garis bawah pada awal nama bidang pribadi, dan nama metode umumnya dianggap sebagai norma di lingkaran pengembangan C #. Dengan beradaptasi dengan konvensi-konvensi tersebut kode Anda akan segera lebih mudah dipahami oleh pengembang lain karena itu adalah kerangka berpikir yang biasa mereka gunakan untuk beroperasi.

Akhiran Label, RadioButton, dll. Untuk kontrol Anda umumnya dianggap sebagai norma juga. Beberapa kontrol yang sering akan ada untuk konsep tunggal (misalnya Label dan TextBox), dan akhiran ini cukup berguna. Notasi Hungaria sejati telah ditinggalkan sejak lama karena telah dibastardisasi menjadi sesuatu yang tidak mengekspresikan maksud aslinya, yang merupakan konteks tentang variabel bukan jenis, ukuran, dll.

— Charles Lambert
sumber

1

Dalam kasus saya, menggunakan camelcase dan garis bawah membantu dengan nama variabel deskriptif (baca: panjang) dan penyelesaian kode. Saya tidak begitu yakin bagaimana pelengkapan otomatis Visual Studio bekerja tetapi di QtCreator dan pada tingkat yang lebih rendah, Eclipse, seseorang dapat mengetik, misalnya

sDI

dan telah diperluas ke

someDescriptiveIdentifier

Menghemat sedikit pengetikan jika Anda memiliki nama seperti

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

yang cenderung saya hasilkan ketika dalam "mode penamaan deskriptif".

Dengan menggunakan garis bawah, saya dapat menentukan nama yang ingin saya selesaikan secara otomatis

someDescriptiveIdentifier

atau

_someDescriptiveClassMember

Semoga penjelasan saya cukup jelas :)

— Manjabes
sumber