Cara menyingkat nama variabel [tertutup]

8

Saya selalu berjuang dalam menyingkat nama variabel. Apakah ada standar untuk menyingkat nama variabel?

Huzaifa
sumber
1
Apakah ini duplikat dari stackoverflow.com/questions/4358840/… ?
11
Ambil petunjuknya. Jika sulit, maka berhentilah melakukannya.
S.Lott
3
Bekerja dengan pengidentifikasi yang disingkat dalam kode yang tidak Anda tulis menyebabkan kerusakan otak.
Rick Sladkey
2
mengikuti aturan secara kaku adalah penyebab atau tanda kerusakan otak. Either way, yang penting adalah penilaian.
T Duncan Smith
1
@ T Duncan Smith: Dari mana asalnya? Anda baru tahu bahwa mereka yang setuju dengan jawaban yang diterima untuk pertanyaan ini memiliki kerusakan otak. Saya hanya bercanda bahwa saya merasa sulit untuk membaca kode rahasia.
Rick Sladkey

Jawaban:

66

Standar yang saya gunakan adalah untuk tidak menyingkat nama variabel kecuali jika singkatan lebih mudah dibaca daripada versi lengkap (misalnya iuntuk indeks iterasi). Kami menyebutkan beberapa hal sehingga kami dapat berkomunikasi. Menyingkat nama variabel biasanya hanya mengurangi kemampuan mereka untuk berkomunikasi.

Rein Henrichs
sumber
5
Tidak yakin saya sepenuhnya setuju. Saya tidak menyingkat banyak, tetapi saya pikir bahwa menyingkat dalam beberapa kasus adalah ide yang baik. Saya akan menemukan nama-nama variabel panjang dalam cakupan lokal yang singkat sangat mengganggu, sebenarnya. Saya menulis banyak fungsi di mana "p" mengacu pada titik dalam 3-ruang. Saya pikir itu sejelas "thePoint," dan lebih mudah dibaca, jika fungsinya dimaksudkan untuk beroperasi pada suatu titik dengan cara tertentu.
T Duncan Smith
4
Seperti yang saya katakan, saya lebih suka nama lengkap "kecuali singkatan lebih mudah dibaca". Sepertinya kita benar-benar setuju.
Rein Henrichs
@Duncan, mungkin itu jelas bagi Anda, tetapi tidak semua orang akan segera melihat korelasi antara singkatan dan apa yang sebenarnya Anda maksudkan. Saya pikir semua variabel harus sepenuhnya deskriptif, kecuali Anda dapat membuatnya segera dimengerti oleh semua pengguna lain. Seperti yang dinyatakan Rein menggunakan 'i' dalam satu lingkaran adalah salah satu skenario di mana saya percaya itu bisa diterima.
Darren Young
1
Saya hampir setuju. Saya akan mengatakan, jangan menyingkat, kecuali singkatan itu sangat umum, bahwa tidak ada keraguan untuk apa singkatannya. Contoh yang baik adalah System.IO. Common juga bisa menjadi umum di perusahaan tempat Anda bekerja. Itu tentu saja berarti bahwa karyawan baru tidak akan tahu persis apa artinya. Tetapi menjadi bagian dari perusahaan berarti cepat atau lambat mereka akan mempelajari istilah perusahaan.
Pete
3
@Duncan Saya dengan senang hati menyingkirkan apa pun yang tidak benar-benar menyampaikan informasi sebagai imbalan karena tidak menyingkat sisanya. "thePoint" adalah hewan peliharaan yang membenci saya karena "the" tidak memberikan kontribusi apa-apa - tetapi masih dapat diperburuk dengan menyingkat menjadi "thePt" daripada "point" atau "p".
Julia Hayward
13

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.

T Duncan Smith
sumber
Menarik, dengan asumsi Anda menggunakan studio visual, saya tidak akan menyingkat parameter karena mereka akan muncul segera setelah Anda mengetik "myfunc (" dan Anda tidak ingin mengatakannya double createBox(string tb, int cir, double pmj), hanya ingin menambahkan
Mark Lalor
Saya terutama menggunakan emacs. Saya agak seperti dinosaurus, tetapi saya juga harus bekerja dengan beberapa bahasa (pada saat yang sama, dalam kode yang sama) di sejumlah platform. Saya kadang-kadang menyingkat parameter jika singkatannya jelas (dan konsisten,) karena saya mencoba untuk fungsi yang cukup pendek sehingga saya bisa melihat semuanya pada satu halaman, tetapi saya sering tidak, karena saya melakukan yang terbaik untuk membuat fungsi tanda tangan tetap pendek. . Yang paling penting adalah konsistensi meskipun- jika parameter "sama" (secara konseptual) disingkat di satu tempat itu harus selalu seperti itu.
T Duncan Smith
1
Pokoknya, titik utama di sini, IMHO, bahkan tidak membiarkan Anda secara otomatis mengetik hal yang benar tanpa mencarinya (meskipun itu bonus.) Poin utamanya adalah mengurangi beban kognitif saat membaca kode nanti. Ini klise, tetapi Anda cenderung membaca bahkan kode Anda sendiri jauh lebih banyak daripada saat Anda menulisnya. Jika ide-ide penting pada dasarnya sulit, Anda ingin menghilangkan beban kognitif yang tidak penting sebanyak yang Anda bisa. Konsistensi membantu di sini. Ini adalah ideal yang mustahil, tetapi kode ideal seharusnya hanya mengandung kesulitan yang tidak dapat direduksi.
T Duncan Smith
7

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.

mattnz
sumber
3
Jika saya melihatnya di luar konteks saya tidak akan tahu apa arti accBalInSaving. Ini juga sama panjangnya dengan tabunganBalance
Richard Tingle
Jika seseorang mendapati dirinya harus menggunakan variabel like accBalInSaving, maka ada yang salah dengan desain - variabel tersebut membawa terlalu banyak info konteks yang sebenarnya harus implisit; jika itu adalah properti Accountkelas, 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.
Konrad Morawski
3

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.

Richard
sumber
2

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.


sumber
2

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 grepatau 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, idan jumum 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.

pengguna52889
sumber
0

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.

Gaurav Sehgal
sumber
2
Saya akan keliru accBalInSavinguntukaccumulated Bal In Savings
KajMagnus
-4

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;
dewa llamas
sumber
1
Ini tidak apa-apa untuk jawaban yang sudah diberikan
Jan Doggen