Saya selalu berjuang dalam menyingkat nama variabel. Apakah ada standar untuk menyingkat nama variabel?
Saya selalu berjuang dalam menyingkat nama variabel. Apakah ada standar untuk menyingkat nama variabel?
Jawaban:
Standar yang saya gunakan adalah untuk tidak menyingkat nama variabel kecuali jika singkatan lebih mudah dibaca daripada versi lengkap (misalnya i
untuk indeks iterasi). Kami menyebutkan beberapa hal sehingga kami dapat berkomunikasi. Menyingkat nama variabel biasanya hanya mengurangi kemampuan mereka untuk berkomunikasi.
Saya bukan programmer C #, jadi saya tidak bisa memberi Anda banyak nasihat tentang konvensi C #. Tetapi saya memiliki beberapa pemikiran tentang singkatan.
Seiring bertambahnya usia dan semakin banyak pengalaman, saya mendapati diri saya semakin kurang. Saya akui bahwa saya bukan pengetik yang sangat baik ketika saya mulai pemrograman. Saya menjadi lebih baik sejak itu;). Saya akan menyingkat secara bebas untuk variabel yang memiliki ruang lingkup yang sangat terbatas, sehingga saya dapat melihat seluruh hidup mereka di satu layar. Tapi selain itu saya lebih suka tidak melakukannya jika saya bisa menghindarinya - saya tidak pernah menyingkat untuk menghemat mengetik.
Saya masih mencoba untuk menjaga garis saya di bawah 80 karakter. Saya tidak yakin apakah itu masuk akal akhir-akhir ini, tetapi itu adalah kebiasaan lama. Jadi saya akan menyingkat jika nama variabel akan menjadi sangat panjang. Tetapi sebelum saya melakukan itu saya akan mencoba untuk menemukan nama yang lebih ringkas yang juga sama jelasnya - semua yang lain lebih pendek lebih baik (berbicara tentang formulir yang diperluas.)
Di mana Anda menyingkat itu yang paling penting, saya pikir, bahwa Anda selalu menyingkat dengan cara yang sama dalam basis kode yang diberikan, dan di seluruh basis kode terkait. Insting pertama Anda kemungkinan adalah insting Anda, karena akan lebih mudah bagi Anda untuk mengingatnya, tetapi bisa juga patut dicoba dengan orang lain di proyek yang sama. Saat ini saya bekerja terutama dengan satu programmer lain, di kantor terbuka yang penuh dengan non-programmer. Mereka pikir kita gila, karena kita sering berdiskusi secara terperinci tentang hal-hal seperti bagaimana secara konsisten menyingkat nama variabel terkait, atau secara konsisten memesan parameter dalam pemanggilan fungsi, dll. Tetapi masalah penamaan, bahkan untuk dua orang. Pada tim yang lebih besar itu menjadi lebih penting. Satu hal yang saya cukup religius adalah memperbaiki ketidakkonsistenan dalam hal-hal seperti ini begitu saya menemukannya.
EDIT: beberapa singkatan bagus, saya pikir. Dalam pekerjaan saya saat ini, banyak kode yang saya tulis berkaitan dengan mengevaluasi splines, dan fungsi parametrik lainnya, pada nilai parameter tertentu. Basis kode kami pada kenyataannya tidak konsisten dalam hal ini. Saya tahu bahwa Anda digunakan di beberapa tempat dan param (singkatan itu sendiri) digunakan di tempat lain. U adalah singkatan yang dipahami secara umum untuk parameter dalam domain ini, jadi saya pikir kita harus melalui dan membuat ini konsisten. Saya akan baik-baik saja dengan salah satu dari u, param, atau parameter. Kami menggunakannya sangat banyak sehingga tidak akan ada kebingungan, selama kami hanya menggunakan satu . Tapi saya lebih suka kamu.
Ini lebih buruk dari itu - kami sebenarnya memiliki beberapa jenis parameter. Dan kami memiliki lebih dari satu nama untuk beberapa dari mereka - uggh.
Alasan ini menjadi tidak konsisten adalah buku teks. Ternyata kami harus memetakan antara enam ruang parameter- alasannya rumit, tetapi pada dasarnya kami harus memiliki parameter yang sesuai dengan ruang parameter, ruang parameter dinormalisasi, ruang panjang busur, ruang panjang busur dinormalisasi, ruang piecewise, dan dinormalisasi ruang piecewise. Kami tidak menyadari, pada awalnya, bahwa kami harus memetakan bolak-balik antara semua ruang ini. Dan kami tidak konsisten dalam bagaimana kami menamai parameter yang menggambarkan titik-titik dalam ruang tersebut.
Ini kadang-kadang terjadi - aplikasi Anda tumbuh, dan Anda melakukan beberapa hal yang tidak konsisten saat menumbuhkannya. Yang penting adalah Anda menyadari bahwa Anda telah menjadi berantakan dan masuk dan memperbaikinya sebelum kekacauan itu menginfeksi segalanya dan Anda berakhir dengan tumpukan puing-puing.
double createBox(string tb, int cir, double pmj)
, hanya ingin menambahkan
The vry rsn w d't bbrvt st mk sr th cd s rdbl nd mntnbl eg
int akunBalanceInSavings
-> bisa disingkat
int accBalInSaving
Perhatikan bahwa dua dari empat kata tersebut adalah shortend (account-> acc dan Balance-> Bal), tetapi dua lainnya tidak. Aturan apa yang diterapkan di sini -memilih 2 kata pertama, itu bukan "kata-kata di atas 6 huruf", karena 2 7 huruf itu dulu dan ada yang tidak.
Jadi bisa / haruskah 'accBalInSav', yuk yuk yuk .......
Pengalaman saya sebagai programmer semakin tua dan lebih bijaksana, mereka semakin kurang. Pada usia saya, kita mungkin mencoba untuk menebus dosa-dosa masa muda kita .....
Ingatlah bahwa kode ini ditulis sekali (ok, banyak beberapa lebih dari sekali) dan dibaca ribuan kali.
accBalInSaving
, maka ada yang salah dengan desain - variabel tersebut membawa terlalu banyak info konteks yang sebenarnya harus implisit; jika itu adalah properti Account
kelas, misalnya, tidak perlu memasukkan "akun" dalam namanya. Dan ketika itu masalahnya, menyingkat hanyalah obat penghilang rasa sakit yang membantu menyapu masalah ini di bawah permadani.
Ada pertanyaan serupa tentang nama karakter tunggal, Menggunakan karakter tunggal untuk nama variabel dalam loop / pengecualian .
Maka jawaban saya seperti sekarang adalah membuat mereka singkat di mana ruang lingkup kecil. Misalnya, parameter fungsi pendek lebih mudah dibaca jika pendek dan membutuhkan lebih sedikit ruang. Variabel kelas lebar harus sangat deskriptif.
Buku klasik Steve McConnell , Code Complete sangat bagus untuk hal-hal seperti ini.
Saya tidak percaya ada aturan resmi atau umum untuk singkatan. Biasanya sistem singkatan dikembangkan oleh masing-masing individu dan dalam setiap proyek individu. Mungkin ada aturan tertentu untuk kebijakan gaya kode sumber perusahaan tetapi itu juga akan bervariasi berdasarkan perusahaan.
Di samping catatan, mengapa disingkat sama sekali? Yang akan menghasilkan hanya Anda yang mengerti apa arti singkatan. Gunakan nama lengkap dan deskriptif untuk variabel. Itu akan mengarah pada kode dokumentasi diri.
Jika ragu, jelaskan.
Inti dari nama variabel adalah agar makna kode lebih jelas. Kecuali jika singkatannya sangat jelas, maka Anda mungkin hanya menggunakan yang terkecil. Nama variabel dan nama fungsi biasanya merupakan satu-satunya bagian dari bahasa manusia dalam kode dan bertindak sebagai 'landmark' bagi mata manusia untuk menemukan bagian kode yang relevan (atau, dalam basis kode besar, alat seperti grep
atau ack
) dan juga sebagai petunjuk untuk pemahaman.
Ketika orang berikutnya datang untuk membaca kode Anda, mereka akan berterima kasih untuk itu. Orang itu bisa jadi Anda dalam waktu satu tahun. Saya memiliki banyak kode yang saya sesalkan, jadi sekarang saya mencoba menghindarinya.
Tidak apa-apa untuk menyingkat ketika ...
... Ketika bentuk singkatan digunakan dalam bahasa Inggris lisan atau tulisan oleh lebih dari sekedar orang yang mengerjakan proyek Anda (banyak kamus memberikan informasi semacam ini di sebelah istilah yang mereka tetapkan).
var extensible_markup_language_element; // don't do this
var xml_element; // better
var element; // possible if the name of the function or the documentation make it clear you're dealing with XML and not the periodic table
docs.toString(); // most people capable of reading code know docs == documentation
... Ketika singkatan merujuk dengan jelas ke satu konsep dan akan langsung dikenali oleh seseorang yang tidak terbiasa dengan basis kode. Bahkan kemudian komentar atau sepotong dokumentasi membantu.
var auth = user.auth;
if (auth) // If the user is authenticated?
// If the user is authorised to do something?
// If the authentication function exists for that user group?
// If some setting called auth is turned on for that user?
// If the user is the author of the document in question?
// If the user has some authority?
var attrNames = retrieveAttrs();
if (attrNames) // hm, attrNames sounds like an array of strings - which will be boolean true even if empty - this if looks like a bug!
const MDF // author is writing an iOS app for ordering hand-carved artisanal fibreboard so anyone familiar with the problem domain knows this has plainly nothing to do with Microsoft Database Files. Though maybe the first time it comes up in the code the author should perhaps still put its full name
... Ketika nama variabel hanya ada dalam lingkup tunggal atau fungsi kecil, dan Anda tidak mengharapkan pengguna untuk mendapatkan makna dari nama, gunakan satu karakter. Dalam kasus seperti itu, i
dan j
umum terjadi.
foreach $i (1..10) { say $announcement->[$i] }
... Saat menulis antarmuka (yaitu bukan nama variabel, jadi di luar lingkup pertanyaan, disebutkan hanya karena nama variabel dan antarmuka yang mengaturnya sering menggunakan kosakata yang sama) dalam hal ini aturan lain mungkin berlaku, misalnya:
some_command --transaction-message "Done" # a bit wordy - keep, but ALSO allow for convenience:
some_command --msg "Done" # might be useful
some_command -m "Done" # if you can spare -m
... Ketika basis kode Anda perlu merujuk ke konsep yang sama berkali-kali dalam proyek yang sama dan ketika singkatan dapat didefinisikan dalam panduan gaya untuk proyek itu, dan ketika itu tidak ambigu. Jika proyek Anda tidak cukup besar untuk panduan gaya maka itu tidak cukup besar untuk itu layak.
Saya tidak akan memberikan contoh kode untuk yang ini karena menurut definisi itu hanya berfungsi dalam proyek besar, tetapi lihat juga item berikutnya:
... Saat mengerjakan proyek mapan yang memiliki banyak kontributor dan panduan gaya yang mengharuskan singkatan. Dalam hal ini, disingkat hanya sesuai dengan panduan gaya, tetapi perhatikan masalah dan bersiaplah untuk membuat catatan dengan komentar (seperti "ini adalah daftar nama atribut sebagai string").
Jenis harus diakhiri dengan “_t”; Definisi struct mentah dalam “_struct”
- https://metacpan.org/source/SHLOMIF/XML-LibXML-2.0117/HACKING.txt
Satu pemikiran terakhir: jika Anda masih memiliki nama variabel panjang yang tidak dapat diterima (mis. Terdiri dari empat atau lebih unit semantik seperti totalAfterTaxInLocalCurrency), itu bisa menjadi gejala bahwa kode Anda mencoba melakukan terlalu banyak dalam satu cakupan tunggal dan fungsinya perlu direaktor ulang keluar atau variabel Anda mungkin lebih dikelola secara logis dalam satu objek.
Alasan kami menyingkat variabel adalah untuk berhenti mengetik variabel besar, tetapi di sisi yang sama variabel yang disingkat harus cukup eksplisit sehingga Anda dapat memahami apa yang dipegangnya daripada kembali ke tempat itu dinyatakan atau dipakai sebelumnya. Jadi misalnya:
int akunBalanceInSavings
-> bisa disingkat
int accBalInSaving
---> tetapi menyingkatnya menjadi
int accBal
Pasti tidak akan menjadi pilihan yang baik karena orang tidak akan dapat memahami apa yang dipegang oleh variabel hanya dengan melihatnya.
accBalInSaving
untukaccumulated Bal In Savings
Anda tidak boleh menyingkat barang demi menyingkat barang, Anda harus melakukannya untuk kenyamanan Anda / orang lain, tetapi jika Anda ingin maka aturan umum yang saya miliki untuk singkatan adalah jika sebuah kata lebih dari empat atau lima huruf maka Saya akan mempersingkat menjadi tiga huruf pertama yang signifikan dari kata itu, misalnya:
int damagePerSecond;
dapat disingkat menjadi
int dmgPerSec;
atau jika Anda menginginkannya sesingkat mungkin,
int dps;