Berjuang untuk tidak menggunakan notasi Hongaria

10

Saya telah melihat argumen untuk dan melawan Sistem Hungaria . Selama beberapa tahun saya telah mengerjakan proyek lawas yang menggunakan sistem ini dengan memberi nama setiap variabel, berfungsi dengan awalan dari tipe variabel mis (strName, intAge, btnSubmit dll) (Saya tahu awalan Apps Hongaria asli dengan jenis variabel, bukan tipe). Saya ingin proyek saya selanjutnya mengabaikannya sepenuhnya, tetapi saya merasa lebih sulit untuk menyebutkan hal-hal serupa secara unik tanpa menggunakan itu.

Katakanlah saya memiliki formulir web untuk mengumpulkan alamat email dan menyimpannya dalam tabel database, dan tombol yang memanggil fungsi yang menyimpan alamat ke db.

Jika saya menggunakan notasi gaya Hungaria, saya bisa menyebut kotak txtEmailtombol btnEmaildan nilai yang terkandung dalam kotak teks strEmail. Saya kemudian dapat menggunakan fungsi storeEmail(strEmail)untuk menyimpan email. Saya memiliki konvensi yang jelas di sini, jelas apa masing-masing variabel.

Apa yang akan menjadi praktik terbaik untuk penamaan variabel-variabel ini

tanpa menggunakan Sistem Hungaria,
tanpa membuatnya terlalu panjang atau membingungkan
dan dengan konvensi yang jelas untuk digunakan di seluruh proyek saya?

naming hungarian

— ketakutan
sumber

2

Mungkin ada yang salah dengan sisa konvensi penamaan Anda, atau ukuran fungsi Anda, jika Anda kesulitan menemukan nama unik.

Teknologi apa yang Anda gunakan? Awalan ini tampaknya meminjamkan diri ke Formulir Web.

— StuperUser

Saya menggunakan ASP.NET (dengan C # di belakang)

— fearoffours

@delnan - bisakah Anda menjelaskannya? Mengapa ukuran fungsi membuat penamaan yang unik lebih mudah?

— fearoffours

@fearofours: Fungsi yang lebih kecil membutuhkan lebih sedikit variabel, dan lebih sedikit variabel jelas berarti lebih sedikit benturan variabel. Itu tentu saja dengan asumsi Anda menempatkan setiap variabel dalam ruang lingkup sekecil mungkin.

8

Poin terakhir Anda adalah yang paling penting - apa pun yang Anda lakukan, Anda harus konsisten di seluruh proyek dan dengan kolega Anda. Ada dua cara utama untuk mencapai konsistensi dan jika mungkin Anda harus menggunakan keduanya. Pertama-tama gunakan alat untuk memeriksa konvensi penamaan pada waktu membangun. Di dunia .Net, StyleCop akan menjadi contoh yang baik untuk alat semacam itu. Cara kedua untuk mendapatkan konsistensi adalah memiliki ulasan sejawat dari semua kode, sehingga Anda semua bisa terus mengawasi.

Dua poin Anda yang lain sepertinya menanyakan alternatif. Saya tidak yakin Anda membutuhkan alternatif; titik tentang Hongaria tidak lagi menjadi populer adalah bahwa dulu digunakan untuk mendeskripsikan jenis ketika sistem jenis dan alat sedikit, harus kita katakan, kurang ketat. Yaitu jika Anda memprogram dalam C dan melewati pointer di sekitar satu-satunya cara untuk melacak tipe adalah dengan menggunakan bahasa Hongaria. Sekarang, jika Anda menggunakan bahasa seperti C # atau Java, Anda tidak akan menggunakan pointer (atau sangat jarang), sehingga kebutuhan untuk segala jenis bahasa Hongaria hilang. Juga, IDE modern memungkinkan Anda melihat tipe dengan sangat mudah dengan mengarahkan kursor ke variabel atau paling buruk menggunakan jalan pintas untuk melihat deklarasi asli. Jadi, saya rasa Anda tidak perlu notasi apa pun, cukup beri nama variabelnya sesuai dengan fungsinya. Jika itu alamat email, gunakan "email" atau "

— Steve
sumber

2

Menjadi sedikit rumit ketika formulir / halaman / jendela / apa pun yang memiliki tombol untuk email, kotak teks untuk email, dan mungkin widget / kontrol lain untuk email ...

— FrustratedWithFormsDesigner

7

@FrustratedWithFormsDesigner Belum tentu. Kotak teks bisa berupa emailAddressInput di mana tombolnya berupa emailAddressSubmit dan representasi internal hanya berupa emailAddress.

— Jonathan

@ Jonathan: Poin bagus.

— FrustratedWithFormsDesigner

3

Saat berhadapan dengan formulir web / formulir Windows / hal-hal grafis lainnya, masuk akal untuk menggunakan Sistem Hongaria karena Anda dapat memiliki kontrol yang sangat terikat bersama-sama — misalnya, kotak teks dan label yang menyatu; Anda mungkin menamainya txtEmaildan lblEmailmembedakannya. Dalam pengalaman saya, ini biasa dan sebenarnya berguna.

Tetapi di belakang kode Anda, penamaan seperti ini tidak perlu. Jika Anda memiliki variabel tipe stringyang digunakan untuk menyimpan email, cukup beri nama email. Jika, karena suatu alasan, Anda menjadi bingung, sebagian besar IDE seharusnya memungkinkan Anda untuk mengarahkan kursornya dan melihat tipenya. (Idealnya, dalam hal-hal OO, itu mungkin atribut dari beberapa objek, dan user.Emailbahkan lebih jelas.)

Saya pikir jika Anda memiliki lebih dari satu objek yang dinyatakan dalam kode Anda yang bukan kontrol GUI yang bisa dinamai email, ada sesuatu yang salah dengan desain Anda.

— Andrew Arnold
sumber

1

Sebenarnya txt dan lbl bukan Hongaria, txt hanya pendek untuk Teks dan lbl pendek untuk Label, tidak ada alasan untuk tidak hanya menggunakan kata panjang penuh misalnya EmailText dan EmailLabel pada formulir. Hongaria adalah tipe, yang dalam kedua kasus ini adalah string.

— Steve

1

@Steve Haigh - Tidak, saya berbicara tentang kontrol sendiri. Anda memiliki objek tipe "textbox" yang disebut txtEmail, dan objek tipe "label" bernama lblEmail. Tak satu pun dari mereka adalah string. Mereka mungkin memiliki properti string, tetapi mereka bukan string sendiri.

— Andrew Arnold

1

Ah maaf. Ya tentu saja. Meski begitu, tidak ada alasan untuk tidak menggunakan nama yang lebih deskriptif seperti EmailTextBox. Hanya karena VS menghasilkan nama yang buruk tidak berarti Anda harus menyimpannya. Namun, dalam konteks bentuk, singkatan txt dan lbl sangat dipahami saya mungkin tidak akan khawatir dalam kasus itu.

— Steve

3

Apa yang membuat variabel "terlalu panjang"?

Alih-alih txtEmail, btnEmailAnda bisa menggunakan UserEmailText, UserEmailButton, dan AdminEmailText,AdminEmailButton

Masalah dengan ini adalah Anda mungkin mulai merasa bahwa variabel mulai menjadi panjang:

AdminEmailIsValid mulai batas pada berapa lama saya akan membiarkan variabel.

Selain itu, Anda mungkin mulai memperhatikan bahwa Anda menggunakan kembali satu set variabel, dan satu set operasi pada variabel itu. Untuk itulah OOP dirancang . Alih-alih seperangkat variabel, buat objek generik:

class EmailForm
  var textBox, button, text
  function storeEmail()

Kemudian Anda bisa instantiate variabel baru sebagai kelas, dan menggunakan notasi titik yang sama untuk mengakses data Anda:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Tentu saja, ini ditargetkan ke bahasa-bahasa yang menggunakan paradigma OOP, tetapi mayoritas bahasa pengembangan web populer berorientasi objek, atau memungkinkan kode berorientasi objek (PHP, Python, C #, C ++, Java ++, Java, JavaScript, ActionScript, dll. ).

— zzzzBov
sumber

Saya gagal melihat keuntungan dari UserEmailText untuk txtEmail - Anda hanya menggunakan tipe suffix daripada membuatnya awalan. Saya suka "Ini adalah apa OOP dirancang untuk", meskipun.

— fearoffours

@fearoffours, OP mengaku memiliki masalah dengan nama-nama unik, saya menambahkan contoh itu sebagai cara deskriptif untuk membedakan antara dua variabel yang sama ( UserEmailTextdan AdminEmailTextkhususnya). Saya biasanya tipe akhiran karena cocok untuk pindah ke kelas UserEmailText-> UserEmail.text-> User.email.texttergantung pada berapa banyak abstraksi / fungsionalitas yang diperlukan.

— zzzzBov

OK, lihat dari mana asalmu. +1 untuk perbandingan akhiran / kelas. Oh, dan saya OP!

— fearoffours

@ takut, lol whoops ...

— zzzzBov