Apakah Anda awalan nama variabel dengan singkatan dari tipe variabel? (Notasi Hongaria) [ditutup]

Dalam pekerjaan saya saat ini, tidak ada pedoman pengkodean. Semua orang cukup banyak kode sesuai keinginannya. Itu bagus, karena perusahaannya kecil.

Namun, seorang pria baru-baru ini mengusulkan untuk selalu menggunakan Notasi Hongaria. Sampai sekarang, sebagian dari kita menggunakan semacam Notasi Hongaria, sebagian dari kita tidak. Anda tahu, ini adalah perusahaan teknik, jadi gaya pengkodean tidak terlalu penting asalkan algoritmenya bagus.

Secara pribadi, saya merasa bahwa singkatan tipe kecil ini agak berlebihan. Nama yang dipikirkan dengan baik biasanya memberikan pesan yang sama. (Selanjutnya, sebagian besar kode kami harus dijalankan pada beberapa DSP aneh, di mana konsep suka boolatau floattidak ada pula).

Jadi, bagaimana perasaan Anda tentang Notasi Hongaria? Apakah Anda menggunakannya? Mengapa?

Ketika kebanyakan orang mengatakan "Notasi Hongaria" mereka sebenarnya berbicara tentang " Sistem Hongaria ".

Sistem Hongaria sama sekali tidak berguna dan harus dihindari. Tidak perlu menyandikan tipe variabel dalam nama itu. Namun, Sistem Hongaria sebenarnya adalah kesalahpahaman dari bahasa Hongaria " asli " yang asli: Aplikasi Hongaria.

Di Apps Hungarian, Anda tidak menyandikan "tipe" di nama variabel, Anda menyandikan "jenis" variabel. Jadi tidak nWidth, tetapi pxWidthatau emWidth(masing-masing untuk "lebar dalam piksel" atau "lebar dalam ems). Tidak strNamekecuali sNameatau usName(masing-masing untuk "nama aman" atau "nama tidak aman" - berguna ketika menerima input dari pengguna: string tidak aman).

Secara pribadi, saya biasanya tidak peduli dengan baik. Kecuali jika saya melakukan sesuatu yang secara eksplisit mengubah "jenis" suatu nilai (misalnya, saya telah menggunakan awalan "px" dan "em" di masa lalu karena membuat kesalahan pxArea = emWidth * emHeighttampak jelas).

Lihat juga, artikel Joel, " Membuat Kode yang Salah Terlihat Salah ."

kata kerjaAnda kata kerjaHarus adverbTidak pernah kata kerjaGunakan kata sifatHunarian nounNotation, prepositionIndo kata kerjaAkibat kolektifuntukunun adverb segala sesuatuJadi perbandingan kata sifatBerbanding kata sifatBerkat infinitif terlalu tinggi untuk kata kerjaBaca.

Pertama:

Anda tahu, ini adalah perusahaan teknik, jadi gaya pengkodean tidak terlalu penting asalkan algoritmenya bagus.

Gaya pengkodean menjadi masalah terlepas dari perusahaan. Ya, algoritme harus baik, tetapi kode harus dipelihara oleh semua orang, bukan hanya pengembang asli. Memiliki standar pengkodean yang mencakup elemen gaya perlu beberapa cara untuk mencapainya. Saya tidak mengatakan semua kode harus identik dalam gaya - itu akan menjadi kontra produktif, tetapi harus ada tingkat konsistensi.

Sekarang ke notasi Hongaria:

Meskipun memiliki kegunaannya, dengan IDE modern yang mendukung perilaku tipe IntelliSense, tidak perlu menyertakan jenis variabel dalam namanya. Informasi ini tersedia untuk Anda dengan cara lain. Lebih buruk lagi dapat membuat kode lebih sulit untuk dibaca jika Anda harus mengubah jenis variabel di masa depan.

Jangan gunakan itu. Itu berlebihan dan membuat kode lebih sulit dibaca.

Banyak perdebatan tentang (Sistem) Notasi Hongaria tergantung pada bidang pekerjaan. Saya dulu sangat tegas di sisi "tidak mungkin!", Tetapi setelah bekerja selama beberapa tahun di sebuah perusahaan di mana ia digunakan untuk pengembangan tertanam saya dapat melihat beberapa keuntungan dari itu dalam aplikasi tertentu dan sudah pasti tumbuh pada saya .

Sistem Hongaria

Dari apa yang bisa saya katakan, Sistem Hongaria cenderung banyak digunakan di bidang tertanam. Dalam aplikasi PC, kompiler akan menangani banyak masalah yang terkait dengan perbedaan antara (misalnya) nilai string, integer dan floating point. Pada platform yang tertanam dalam, Anda lebih sering khawatir tentang perbedaan antara bilangan bulat 8-bit yang tidak ditandatangani, bilangan bulat bertanda 16-bit dll. Kompilator (atau bahkan serat dengan aturan MISRA ditegakkan) tidak selalu mengambil ini. Dalam hal ini memiliki nama variabel seperti u8ReadIndex, s16ADCValuedapat bermanfaat.

Aplikasi Hungaria

Aplikasi Hungarian memiliki keuntungan yang pasti dalam hal aplikasi PC / Web, misalnya menawarkan perbedaan visual antara string 'tidak aman' dan string 'aman' (yaitu yang dimasukkan oleh pengguna dan yang telah melarikan diri atau membaca dari sumber daya internal atau apa pun ). Kompiler tidak memiliki pengetahuan tentang perbedaan ini.

Apa gunanya?

Penggunaan (Sistem atau Aplikasi) Hongaria adalah tentang membuat kode yang salah terlihat salah .

Jika Anda menyalin string yang tidak aman langsung ke string yang aman tanpa melarikan diri, itu akan terlihat salah jika Anda menggunakan Apps Hungarian.

Jika Anda mengalikan integer yang ditandatangani dengan integer yang tidak ditandatangani, kompiler akan (sering kali secara diam-diam) mempromosikan yang ditandatangani menjadi (yang kemungkinan besar) yang tidak ditandatangani, mungkin mengakibatkan kesalahan: Sistem Hongaria membuat ini terlihat salah.

Dalam kedua situasi ini, (Aplikasi / Sistem) notasi Hongaria cenderung membuat ulasan kode formal lebih cepat karena ada kurang merujuk kembali ke jenis variabel.

Secara keseluruhan

Secara keseluruhan, pendapat saya adalah yang paling penting adalah Anda memiliki standar pengkodean. Apakah itu menggunakan Sistem Hungaria, Aplikasi Hungaria atau tidak adalah masalah preferensi pribadi atau kelompok, seperti pilihan jenis indentasi dll. Namun, ada keuntungan yang pasti bagi seluruh tim pengembangan yang bekerja dengan preferensi yang sama.

Tujuan Notasi Hongaria adalah untuk menyandikan informasi ke dalam pengidentifikasi yang tidak dapat dikodekan dalam sistem tipe. Pendapat saya sendiri adalah bahwa jika informasi ini cukup penting untuk dikodekan, maka itu cukup penting untuk dikodekan dalam sistem tipe, di mana ia dapat diperiksa dengan benar. Dan jika informasi itu tidak penting, lalu mengapa Anda ingin mengacaukan kode sumber Anda dengannya?

Atau, lebih tepatnya: ketik informasi yang termasuk dalam sistem tipe. (Catatan: itu tidak harus menjadi sistem tipe statis . Selama itu menangkap kesalahan ketik, saya tidak peduli ketika menangkapnya.)

Beberapa jawaban lain menyebutkan Unit Ukur sebagai penggunaan Notasi Hongaria yang dapat diterima. (Saya agak terkejut bahwa belum ada yang menyebutkan NASA Mars Climate Orbiter, karena itu sepertinya muncul setiap saat dalam diskusi tentang Notasi Hongaria).

Berikut ini contoh sederhana dalam F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Lihat, Bu, jangan orang Hongaria!

Jika saya adalah untuk menggunakan Hungaria Notasi bukan jenis di sini, itu tidak akan membantu saya sedikit:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

Kompiler membiarkannya lurus. Saya sekarang mengandalkan manusia untuk menemukan apa yang pada dasarnya adalah kesalahan tipe. Bukankah itu untuk tipe checker?

Lebih baik lagi, menggunakan bahasa pemrograman Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Jadi, secara ringkas: Saya tidak suka Notasi Hongaria. Anda seharusnya tidak pernah menggunakannya.

Yang sedang berkata, saya pikir menggunakan Notasi Hongaria adalah ide yang baik. Tunggu apa?

Iya nih! Dalam kasus khusus ini , Anda menyebutkan:

Selain itu, sebagian besar kode kami harus dijalankan pada beberapa DSP aneh, di mana konsep seperti bool atau float tidak ada

Tapi itu justru satu-satunya kasus penggunaan masuk akal untuk Hungaria Notasi!

PS: Dengan sepenuh hati saya merekomendasikan untuk melihat Frink. Manualnya berisi beberapa lelucon kentut yang paling mengagumkan yang pernah ada. Ini juga bahasa yang cukup keren :-)

Itu tidak masuk akal dalam bahasa berorientasi objek - semuanya adalah jenis yang jelas ketika mencoba menggunakannya.

Satu-satunya tempat di mana Sistem Hongaria diperingatkan adalah dengan bahasa yang diketik dengan lemah seperti C. Ini sangat penting dengan C karena tidak ada objek eksplisit (ia memiliki struct, tetapi semua fungsi di luar struct). Dalam sesuatu yang diketik lebih kuat seperti C ++, Java, dan C # itu tidak membantu, dan bahkan membuat segalanya menjadi lebih buruk. Perubahan kode, dan jauh lebih mudah untuk mengubah jenis daripada mengubah semua tempat Anda menggunakan nama variabel. Ini juga pekerjaan yang tidak perlu yang cenderung diabaikan.

Jika Anda memiliki unit pengukuran, mungkin membantu untuk menyandikannya dalam nama - tetapi pada akhirnya itu juga bisa menjadi noise tambahan. Misalnya, kami akan mendeklarasikan satuan ukuran standar untuk hal-hal berbeda yang kami kerjakan dalam kode kami. Sebagai contoh, apakah kita menggunakan gradien atau derajat, meter atau kaki, bingkai atau milidetik? Setelah standar ditetapkan untuk kode, setiap kali kami membaca dalam satu unit ukuran, kami selalu segera mengonversi ke unit standar ukuran untuk kode.

Saran saya : mulailah dengan poin rasa sakit Anda saat ini dan pilih standar yang masuk akal untuk bagian kode itu. Menentukan standar pengkodean terlalu kontraproduktif. Ada banyak nilai dalam memiliki nama variabel dan bidang yang menguraikan apa yang mereka wakili, dan sebagian besar waktu Anda dapat menyimpulkan jenis dari konsep dengan aman.

Heck, TIDAK!

Jangan gunakan notasi Hungaria atau notasi lainnya. Sebagai pemrogram, kita tidak boleh menggunakan "notasi" untuk nama variabel kita.

Apa yang harus kita lakukan adalah memberi nama variabel kita dengan baik :

• Hindari nama yang terlalu umum. Jangan zberi nama saat itu adalah variabel kelas yang mewakili objek bernama, katakanlah, tagihan telepon. Sebut phoneBillatau PhoneBill.

• Hindari nama yang terlalu spesifik. Ketika ada sesuatu yang jelas tanpa informasi tambahan jangan sertakan itu. Jika itu hanya variabel indeks string untuk perulangan melalui karakter string, dan Anda hanya menggunakannya sekali dalam fungsi MyFunc, mengapa Anda menyebutnya MyFuncTempStringCharacterIndex? Itu lelucon yang menyedihkan. Sebut Posatau bahkan ijika Anda suka. Dalam konteksnya, programmer selanjutnya akan dengan mudah memahami apa artinya.

• Ketika memusatkan perhatian pada seberapa umum atau spesifik suatu nama seharusnya, pertimbangkan domain itu berada dan konteks makna yang mungkin lainnya. Dalam kasus sempit di mana ada dua item jenis yang mudah bingung, serupa yang digunakan dengan cara yang sama, maka boleh saja untuk membuat awalan atau akhiran untuk menunjukkan perbedaan itu. Jaga agar sesingkat mungkin.

Seperti yang telah dijawab oleh penjawab lain, case sempit ini yang memulai "Apps Hungarian", untuk membedakan antara pengukuran relatif terhadap jendela rwTabPositiondan relatif terhadap dokumen rdTabPosition. Tetapi dalam aplikasi yang melakukan segalanya relatif terhadap dokumen, jangan tambahkan kesalahan ekstra! Bahkan, mengapa tidak menggunakan ide Jörg W Mittag untuk membuat tipe baru yang sebenarnya? Maka Anda tidak mungkin membuat berbagai hal tercampur aduk.

Di hampir semua bidang, menambahkan hal-hal yang memiliki kepadatan makna minimal mengurangi kebermaknaan keseluruhan dan kemudahan pemahaman. Ini salah satu contoh dari Ben Franklin . Dan contoh lain: dimungkinkan dalam bahasa Inggris untuk menghias kata-kata kita dengan bagian bicaranya. Ini lebih banyak informasi, bukan? Kalau-kalau pemula ke Bahasa Inggris bingung, itu bisa sangat membantu mereka, kan? Baca ini dan beri tahu saya seberapa berguna menurut Anda ini untuk pemahaman jangka panjang dan pemberian informasi yang efisien:

vrbDo advnot vrbuse nouHunarian nounotation cnjor adjany adjun nounotation. prepA nouprogrammers, beri tahu kami harus tidak benar-benar menggunakan kata benda "nounotation" kecuali untuk kata benda yang dapat disesuaikan.

Dengan menambahkan informasi, saya membuatnya susah dibaca.

Jadi lupakan notasi. Lupakan awalan khusus yang selalu Anda tambahkan. Menurut pendapat saya, satu-satunya pedoman nyata di sini adalah:

Buat nama variabel sesingkat mungkin, sepenting yang diperlukan, dan selalu jelas .

Tujuan pengidentifikasi lebih penting daripada jenisnya. Jika Anda menggunakan nama deskriptif untuk pengidentifikasi dalam program Anda, Anda tidak perlu menggunakan notasi Hongaria. isConnectedselalu lebih mudah dibaca dan mudah dipahami daripada boolConnected.

Kami menggunakan bahasa Hungaria kembali ketika saya masih seorang programmer C ++, dan itu hebat. Anda bisa melihat tipe variabel (fe BSTR, CString, LPCTSTR, atau char *) tanpa mencari deklarasi. Pada masa itu, Anda akan mencari deklarasi dengan melakukan:

1. ctrl-home
2. ctrl-F
3. nama variabel
4. memasukkan

Jadi itu cukup penting. Tetapi di sekitar tahun 2000, beberapa hal terjadi:

• editor menjadi cukup cerdas untuk menampilkan tipe variabel sebagai tooltip
• editor memiliki jalan pintas "pergi ke deklarasi", dan cara cepat untuk menelusuri kembali
• C ++ lebih sedikit digunakan, dan sebagian besar bahasa lain memiliki lebih sedikit tipe variabel. Misalnya, dalam C #, Anda cukup yakin lastNameadalah System.String, karena hanya ada satu kelas string.

Saya adalah salah satu orang terakhir yang beralih dari bahasa Hongaria, dan sekarang ketika saya membaca kode sumber lama, itu benar-benar mengganggu saya.

Saya hanya benci notasi hungaria, saya lebih suka menggunakan garis bawah untuk membatasi nama variabel.

Selain itu, ketika Anda meletakkan jenis sebagai huruf pertama di awal nama variabel Anda seperti ini: float fvelocity; vect vDirection; string ** ppszWord;

pelengkapan otomatis mengurutkan semuanya, dan Anda kesulitan menemukan apa yang Anda inginkan, dan orang cenderung menggunakan apa yang menurut mereka lebih baik, dan itu bukan notasi lagi.

Saya hanya suka menulis ThingsLikeThat ketika saya harus sangat deskriptif tentang variabel, karena menghemat ruang dan fakta ada topi membuatnya lebih mudah dibaca.

Apa yang biasanya saya lakukan, adalah nama metode dan kelas saya dengan huruf pertama menjadi Huruf besar, dan huruf kecil untuk nama variabel, dan garis bawah untuk nama variabel (Saya menemukan ini yang terakhir berguna).

Serius, saya lebih suka orang memperhatikan aturan-aturan itu: Gunakan koma, aritmatika, dan kawat gigi dengan ruang yang relevan:

void f(int a, char b);
int a = b + 4 / (3 + 4);

Tidak lebih dari 80 karakter per baris, ATAU PALING 90 karakter, gunakan argumen multi-baris untuk fungsi atau panjang if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

Setuju dengan sebagian besar, itu gaya lama.

Dengan IDE modern, kursor cepat ke atas variabel menunjukkan jenisnya.