Apakah ada alasan untuk nama variabel pendek?

Ini menjadi frustrasi besar dengan basis kode yang saat ini saya kerjakan; banyak nama variabel kami pendek dan tidak deskriptif. Saya satu-satunya pengembang yang tersisa di proyek ini, dan tidak ada dokumentasi mengenai apa yang dilakukan kebanyakan dari mereka, jadi saya harus menghabiskan waktu ekstra untuk melacak apa yang mereka wakili.

Sebagai contoh, saya membaca beberapa kode yang memperbarui definisi permukaan optik. Variabel yang ditetapkan pada awal adalah sebagai berikut:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

Mungkin hanya saya, tetapi pada dasarnya tidak memberi tahu saya apa yang mereka wakili, yang membuat memahami kode semakin sulit. Yang saya tahu adalah bahwa itu adalah variabel yang diuraikan baris tertentu dari tabel tertentu, di suatu tempat. Setelah beberapa pencarian, saya menemukan apa artinya:

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

Saya mengganti nama mereka menjadi apa yang saya miliki di sana. Itu memperpanjang beberapa garis, tapi saya merasa itu adalah trade off yang adil. Namun skema penamaan semacam ini digunakan di banyak kode. Saya tidak yakin apakah itu artefak dari pengembang yang belajar dengan bekerja dengan sistem yang lebih lama, atau jika ada alasan yang lebih dalam di baliknya. Apakah ada alasan yang baik untuk menamai variabel dengan cara ini, atau apakah saya dibenarkan memperbarui mereka menjadi nama yang lebih deskriptif saat saya menjumpai variabel?

Tampaknya nama-nama variabel ini didasarkan pada singkatan yang Anda harapkan untuk ditemukan dalam buku teks fisika yang menangani berbagai masalah optik. Ini adalah salah satu situasi di mana nama variabel pendek sering lebih disukai daripada nama variabel yang lebih panjang. Jika Anda memiliki fisikawan (atau orang yang terbiasa mengerjakan persamaan dengan tangan) yang terbiasa menggunakan singkatan umum seperti Rin, Rout, dll. Kode akan jauh lebih jelas dengan singkatan tersebut daripada dengan nama variabel yang lebih panjang. Ini juga membuatnya lebih mudah untuk membandingkan formula dari makalah dan buku teks dengan kode untuk memastikan bahwa kode tersebut benar-benar melakukan perhitungan dengan benar.

Siapa pun yang terbiasa dengan optik akan segera mengenali sesuatu seperti Rin sebagai jari-jari dalam (dalam makalah fisika, yang inakan diterjemahkan sebagai subskrip), Rout sebagai jari-jari luar, dll. Meskipun mereka hampir pasti dapat secara mental menerjemahkan sesuatu seperti innerRadiusnomenklatur yang lebih akrab, melakukan hal itu akan membuat kode kurang jelas bagi orang itu. Itu akan membuatnya lebih sulit untuk menemukan kasus-kasus di mana formula yang sudah dikenal telah dikodekan secara salah dan itu akan membuatnya lebih sulit untuk menerjemahkan persamaan dalam kode ke dan dari persamaan yang akan mereka temukan di kertas atau buku teks.

Jika Anda adalah satu-satunya orang yang pernah melihat kode ini, Anda tidak perlu menerjemahkan antara kode dan persamaan optik standar, dan tidak mungkin bahwa fisikawan akan perlu melihat kode di masa depan mungkin itu tidak masuk akal untuk refactor karena manfaat dari singkatan tidak lagi melebihi biaya. Namun, jika ini adalah pengembangan baru, hampir pasti masuk akal untuk menggunakan singkatan yang sama dalam kode yang akan Anda temukan dalam literatur.

Variabel dengan masa hidup pendek harus diberi nama segera. Sebagai contoh, Anda tidak menulis for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Sebaliknya, Anda gunakan for(int i ....

Secara umum dapat dikatakan bahwa semakin pendek ruang lingkup variabel semakin pendek nama seharusnya. Counter loop sering hanya berupa huruf tunggal, katakanlah i, jdan k. Variabel lokal adalah sesuatu seperti baseatau fromdan to. Variabel global kemudian agak rumit, misalnya EntityTablePointer.

Mungkin aturan seperti ini tidak diikuti dengan basis kode yang Anda gunakan. Itu alasan bagus untuk melakukan beberapa refactoring!

Masalah dengan kode bukanlah nama pendek, melainkan kurangnya komentar yang akan menjelaskan singkatan, atau menunjuk ke beberapa bahan bermanfaat tentang formula dari mana variabel diturunkan.

Kode itu hanya mengasumsikan masalah-keakraban domain.

Itu bagus, karena keakraban masalah-domain mungkin diperlukan untuk memahami dan mempertahankan kode, terutama dalam peran seseorang yang "memiliki" itu, sehingga Anda perlu memperoleh keakraban daripada berkeliling mencari-cari nama yang panjang.

Tapi alangkah baiknya jika kode memberikan beberapa petunjuk untuk berfungsi sebagai loncatan. Bahkan seorang pakar domain bisa melupakan bahwa dKkonstanta berbentuk kerucut. Menambahkan sedikit "lembar contekan" di blok komentar tidak ada salahnya.

Untuk variabel tertentu yang terkenal di domain masalah - seperti kasus yang Anda miliki di sini - nama variabel singkat adalah wajar. Jika saya mengerjakan game, saya ingin entitas game saya memiliki variabel posisi xdan y, bukan horizontalPositiondan verticalPosition. Demikian juga lingkaran counter yang tidak memiliki semantik luar pengindeksan, saya berharap untuk melihat i, j, k.

Menurut "Kode Bersih":

Nama variabel harus:

• Jadilah niat mengungkapkan
• Hindari disinformasi
• Buat perbedaan yang bermakna
• Diucapkan
• Dapat dicari

Pengecualian adalah pepatah yang i,j,k,m,ndigunakan untuk loop.

Variabel nama Anda, memang seharusnya, mengeluh tentang melakukan hal-hal di atas. Nama-nama itu adalah nama yang buruk.

Juga, karena setiap metode harus pendek , menggunakan awalan untuk menunjukkan lingkup atau jenis tidak lagi digunakan.

Nama-nama ini lebih baik:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

Seorang komentator mengatakan bahwa ini akan terlalu kompleks dengan nama variabel panjang:

Nama variabel pendek juga tidak membuatnya menjadi sederhana:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

Jawabannya adalah nama panjang dan hasil antara hingga Anda mendapatkan ini di akhir:

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

Ada dua alasan bagus untuk tidak mengganti nama variabel dalam kode lawas.

(1) kecuali jika Anda menggunakan alat refactoring otomatis, kemungkinan memperkenalkan bug tinggi. Karenanya, "jika tidak rusak, jangan perbaiki"

(2) Anda akan membuat membandingkan versi saat ini dengan versi masa lalu, untuk melihat apa yang berubah, tidak mungkin. Ini akan membuat pemeliharaan kode di masa mendatang lebih sulit.

Apakah ada alasan yang baik untuk menamai variabel dengan cara ini, atau apakah saya dibenarkan memperbarui mereka menjadi nama yang lebih deskriptif saat saya menjumpai variabel?

Alasan untuk menggunakan nama yang lebih kecil adalah jika programmer asli menemukannya lebih mudah untuk dikerjakan. Agaknya mereka memiliki hak untuk menemukan hal tersebut, dan hak untuk tidak memiliki preferensi pribadi yang sama dengan yang Anda miliki. Secara pribadi, saya akan menemukan ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... jika saya menggunakannya dalam perhitungan yang panjang dan rumit. Semakin kecil ekspresi matematika, seringkali semakin mudah untuk melihat semuanya sekaligus. Meskipun jika itu yang terjadi, mereka mungkin lebih baik sebagai dIn dan dOut, jadi tidak ada D berulang yang dapat menyebabkan kesalahan ketik yang mudah.

Di sisi lain, jika Anda merasa lebih sulit untuk diajak bekerja sama, maka benturkan diri Anda dan ubah nama menjadi bentuk yang lebih panjang. Terutama jika Anda bertanggung jawab untuk kode itu.

Secara umum, saya percaya bahwa aturan untuk ini, seharusnya Anda dapat menggunakan nama variabel yang sangat singkat di mana Anda tahu bahwa orang-orang yang "ahli dalam bidang ini" dari kode khusus Anda akan segera memahami referensi nama variabel itu. (Anda selalu memiliki komentar untuk perkecualian kasus ini), dan bahwa penggunaan lokal variabel dapat dengan mudah dilihat berdasarkan konteks bagaimana mereka digunakan.

Untuk memperluas ini, itu berarti bahwa Anda tidak harus keluar dari cara Anda untuk mengaburkan nama variabel Anda, tetapi, Anda dapat menggunakan singkatan untuk nama variabel Anda, di mana Anda tahu bahwa hanya orang-orang yang memahami konsep yang mendasari kode Anda yang cenderung untuk membacanya.

Untuk menggunakan contoh dunia nyata, baru-baru ini, saya membuat kelas Javascript yang akan mengambil garis lintang, dan memberi tahu Anda jumlah sinar matahari yang Anda harapkan pada tanggal tertentu.

Untuk membuat kelas Sundial ini , saya mungkin merujuk pada setengah lusin sumber daya, Astronomi Almanac, dan cuplikan dari bahasa lain, (PHP, Java, C dll).

Dalam hampir semua ini, mereka menggunakan singkatan identik yang serupa, yang pada permukaannya tidak ada artinya sama sekali.

K, T, EPS, deltaPsi, eot, LM,RA

Namun, jika Anda memiliki pengetahuan fisika, Anda dapat memahami apa itu fisika. Saya tidak akan mengharapkan orang lain menyentuh kode ini, jadi mengapa menggunakan nama variabel verbose?

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

Selain itu, sering kali, ketika nama variabel bersifat sementara, artinya, mereka hanya digunakan untuk sementara mengalokasikan beberapa nilai, maka sering kali tidak masuk akal untuk menggunakan versi verbose, terutama ketika konteks variabel menjelaskan tujuannya.

Benar-benar ada; sering kali hanya nama variabel pendek yang diperlukan.

Dalam kasus saya, saya melakukan navigasi waypoint di kelas Robotika senior saya, dan kami memprogram robot kami di KISS-C. Kita memerlukan variabel untuk koordinat sekarang dan tujuan (x, y), jarak (x, y), judul saat ini dan tujuan, serta sudut belok.

Khususnya dalam kasus koordinat x dan y, nama variabel panjang sama sekali tidak perlu, dan nama seperti xC (x saat ini), yD (tujuan y), dan pD (tujuan phi), cukup dan paling mudah untuk dipahami pada kasus ini.

Anda mungkin berpendapat bahwa ini bukan 'nama variabel deskriptif' sebagai protokol programmer akan menentukan, tetapi karena nama didasarkan pada kode sederhana (d = tujuan, c = saat ini), komentar yang sangat sederhana pada awalnya adalah semua deskripsi mereka membutuhkan.

Apakah ada alasan yang baik untuk menamai variabel dengan cara ini, atau apakah saya dibenarkan memperbarui mereka menjadi nama yang lebih deskriptif saat saya menjumpai variabel?

Biasanya, algoritma yang kompleks diimplementasikan dalam matlab (atau bahasa serupa). Apa yang saya lihat adalah orang hanya mengambil alih nama variabel. Dengan begitu, mudah untuk membandingkan implementasi.

Semua jawaban lain hampir benar. Singkatan-singkatan ini dapat ditemukan dalam matematika dan fisika, kecuali mereka tidak dimulai dengan d(seperti pada contoh Anda). Variabel yang dimulai dengan d biasanya dinamai untuk mewakili diferensiasi .

Semua panduan pengkodean normal memberi tahu untuk tidak menyebutkan variabel dengan huruf pertama yang mewakili jenis (seperti dalam kasus Anda), karena sangat mudah untuk menelusuri kode di semua IDE modern.

Saya bisa memikirkan alasan mengapa nama variabel cukup pendek.

Nama-nama pendek mudah dibaca menggunakan rentang mata yang lebih pendek, karenanya rentang perhatian pendek.

Sebagai contoh, begitu saya terbiasa dengan fakta bahwa svdb berarti "simpan ke database", tingkat pemindaian kode sumber menjadi lebih baik karena saya hanya perlu dengan cepat memindai 4 karakter daripada saat membaca SaveToDatabase (14 karakter, semuanya menjadi lebih buruk untuk nama operasi yang lebih kompleks). Saya mengatakan "memindai" bukan "membaca", karena itu mengambil bagian utama dari analisis kode sumber.

Saat memindai melalui sejumlah besar kode sumber, ini dapat memberikan keuntungan kinerja yang baik.

Juga, itu hanya membantu programmer malas untuk mengetikkan nama-nama pendek ini ketika menulis kode.

Tentu saja, semua "singkatan" ini diharapkan akan terdaftar di beberapa lokasi standar dalam kode sumber.

Untuk membingkai apa yang dikatakan @zxcdw dengan cara yang sedikit berbeda, dan menguraikannya dalam hal pendekatan:

Fungsinya harus murni , singkat dan enkapsulasi sempurna dari beberapa fungsionalitas: Logika kotak hitam , terlepas dari apakah ia telah duduk tak tersentuh selama 40 tahun, ia akan terus melakukan pekerjaan yang dirancang untuknya, karena antarmuka (masuk dan keluar) adalah suara, bahkan ketika Anda tidak tahu apa pun tentang internalnya.

Ini adalah jenis kode yang ingin Anda tulis: ini adalah kode yang bertahan, dan mudah untuk port.

Bila perlu, buat fungsi dari panggilan fungsi lainnya (sebaris) , untuk menjaga kode tetap terpelihara.

Sekarang, dengan nama fungsi deskriptif yang sesuai (jika perlu!), Kami meminimalkan kemungkinan salah tafsir atas nama-nama variabel pendek tersebut, karena cakupannya sangat kecil.

Nama variabel harus sejelas mungkin untuk membantu keterbacaan program. Anda mengalaminya sendiri: Anda mengalami banyak kesulitan mengidentifikasi apa yang dilakukan program karena penamaan yang buruk.

Tidak ada alasan bagus untuk tidak menggunakan nama deskriptif. Ini akan membantu Anda, dan semua orang yang bekerja / akan bekerja di proyek. Yah sebenarnya ada satu penggunaan sah untuk nama pendek: loop counter.

Tentunya ini untuk apa // komentar?

Jika tugas memiliki komentar yang deskriptif Anda mendapatkan yang terbaik dari kedua dunia: deskripsi variabel dan persamaan apa pun mudah dibandingkan dengan rekan buku teks mereka.

Untuk antarmuka (misalnya, tanda tangan metode, tanda tangan fungsi) Saya cenderung untuk menyelesaikan ini dengan membubuhi keterangan parameter deklarasi. Untuk C / C ++ ini menghiasi file .h serta kode implementasi.

Saya melakukan hal yang sama untuk deklarasi variabel di mana mengetahui penggunaan variabel tidak jelas dalam konteks dan penamaan. (Ini berlaku dalam bahasa yang tidak memiliki pengetikan kuat juga.)

Ada banyak hal yang kita tidak ingin menyumbat nama variabel. Apakah sudut dalam radian atau derajat, apakah ada toleransi pada presisi atau jangkauan, dll. Informasi dapat memberikan pernyataan berharga tentang karakteristik yang harus ditangani dengan benar.

Saya tidak religius tentang hal itu. Saya hanya tertarik pada kejelasan dan memastikan bahwa saya sekarang adalah apa kali berikutnya diri saya yang pelupa mengunjungi kode. Dan siapa pun yang melihat dari balik pundak saya memiliki apa yang perlu mereka ketahui untuk melihat di mana sesuatu mati, apa yang penting (kritis terakhir untuk perawatan yang tepat).

Apakah ada alasan untuk nama variabel yang terlalu pendek?

Pertama: Memberi nama variabel untuk energi e sambil menghitung formula seperti E = MC2 TIDAK penamaan yang terlalu pendek. Menggunakan simbol sebagai argumen untuk nama pendek tidak valid

Pertanyaan ini agak menarik bagi saya, dan saya hanya bisa memikirkan satu alasan dan itu adalah uang.

Misalnya, Anda menggunakan javascript untuk klien yang mengetahui bahwa file tersebut akan diunduh berkali- kali per detik. Akan lebih murah dan membuat pengalaman pengguna lebih baik jika file (dalam jumlah byte) sekecil mungkin.

(Hanya untuk menjaga contoh 'realistis', Anda tidak diizinkan menggunakan alat minifier, mengapa? Masalah keamanan, tidak ada alat eksternal yang diizinkan menyentuh basis kode.)

Saya perhatikan bahwa jawaban lain tidak menyebutkan penggunaan Notasi Hongaria. Ini ortogonal untuk perdebatan panjang, tetapi relevan dengan skema penamaan pada umumnya.

double dR, dCV, dK, dDin, dDout, dRin, dRout

"D" di awal semua variabel ini dimaksudkan untuk menunjukkan bahwa mereka berlipat ganda; tapi bahasa tetap menerapkan ini. Terlepas dari kesempitan nama-nama ini, mereka hingga 50% berlebihan !

Jika kita akan menggunakan konvensi penamaan untuk mengurangi kesalahan, lebih baik kita menyandikan informasi yang tidak dicek oleh bahasa. Misalnya, tidak ada bahasa yang akan dikeluhkan dK + dRdalam kode di atas, meskipun tidak berarti menambahkan angka tanpa dimensi ke panjang.

Cara yang baik untuk mencegah kesalahan tersebut adalah dengan menggunakan tipe yang lebih kuat; namun, jika kita akan menggunakan ganda maka skema penamaan yang lebih tepat mungkin:

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

Bahasa masih akan memungkinkan kita untuk menulis K + lR, tetapi sekarang nama memberi kita petunjuk bahwa ini mungkin salah.

Ini adalah perbedaan antara Sistem Hungaria (umumnya buruk) dan Aplikasi Hungaria (mungkin bagus)

http://en.wikipedia.org/wiki/Hungarian_notation

Satu- satunya kasus di mana nama variabel pendek yang tidak sah dapat diterima dalam rekayasa perangkat lunak modern adalah ketika mereka ada dalam sebuah skrip dan throughput skrip tersebut (melalui jaringan umumnya) adalah penting. Bahkan kemudian, simpan skrip dengan nama panjang di kontrol sumber, dan perkecil skrip dalam produksi.