Seringkali ketika sintaks bahasa mengharuskan saya untuk memberi nama variabel yang tidak pernah digunakan, saya akan menyebutkannya _
.
Dalam pikiran saya, ini mengurangi kekacauan dan membuat saya fokus pada variabel yang berarti dalam kode. Saya menemukan itu tidak mengganggu sehingga menghasilkan efek "tidak terlihat, keluar dari pikiran".
Contoh umum di mana saya melakukan ini adalah penamaan subqueries di SQL.
SELECT *
FROM
(
SELECT *
FROM TableA
JOIN TableB
ON TableA.ColumnB = TableB.ColumnB
WHERE [ColumnA] > 10
) _ --This name is required, but never used here
ORDER BY ColumnC
Contoh lain adalah variabel loop yang tidak digunakan.
array = [[] for _ in range(n)] # Defines a list of n empty lists in Python
Saya menggunakan teknik ini dengan sangat hemat, hanya ketika saya merasa bahwa nama deskriptif tidak menambahkan kode apa pun, dan dalam beberapa hal menghilangkannya dengan menambahkan lebih banyak nama untuk diingat. Dalam beberapa hal saya melihatnya sebagai mirip dengan var
kata kunci dalam C #, yang saya juga menggunakan hemat.
Rekan kerja saya tidak setuju. Mereka mengatakan bahwa memiliki nama karakter tunggal (alfabet) lebih baik daripada _
.
Apakah aku salah? Apakah praktik yang buruk untuk melakukan ini?
sumber
[table].[column]
pengenal, itu membantu keterbacaan banyak untuk hanya digunakan[T].[column]
. Itu tergantung pada skrip tentunya. Pilih sedikit seperti itu baik-baik saja, tetapi jika skrip itu sangat besar, saya mungkin menggunakan nama yang lebih deskriptif.Jawaban:
Semua nama harus bermakna. Jika
_
itu adalah standar terkenal di perusahaan Anda atau di komunitas yang lebih luas, maka itu akan bermakna sebagai "nama yang tidak penting". Jika tidak, saya akan mengatakan itu adalah praktik yang buruk. Gunakan nama deskriptif untuk apa yang Anda rujuk, terutama karena nama itu mungkin penting di masa depan.sumber
dummy
akan lebih baik,joined_ab
akan lebih baik.Saya akan mengatakan bahwa ini adalah praktik yang dapat diterima. Ini adalah contoh langka di mana saya akan menganggap mayoritas salah dan perlu memperbarui pengetahuan mereka tentang ide-ide pemrograman baru-baru ini. Dalam banyak bahasa, terutama bahasa fungsional berbasis ML seperti Haskell dan OCaml, sangat umum digunakan
_
sebagai variabel "tidak digunakan". Bahkan Lua, yang tidak menawarkan dukungan bahasa eksplisit untuk itu, mendorong penggunaan_
sebagai pengganti dengan konvensi.Beberapa bahasa (Haskell, Lua, dan DI berpikir dari atas kepala saya) juga menawarkan konvensi di mana variabel yang mengarah dengan garis bawah tidak menghasilkan peringatan kompiler tentang "variabel lokal yang tidak digunakan" yang membuat
_
nama variabel terpendek yang tidak terpakai. Anda dapat menggunakan sesuatu seperti_unused
tetapi saya setuju dengan Anda bahwa itu hanya membuat kekacauan.sumber
*
in dalam seleksi adalah hal yang sangat buruk, karena jika tabel mengubah hasil-hasil Anda juga berubah secara tak terduga. Jadi saya biasanya perlu alias karakter tunggal untuk mengidentifikasi kolom yang saya pilih. Jika Anda berhenti menggunakan*
, Anda berhenti membutuhkan nama "tidak digunakan"._
adalah pola, bukan variabel. Ini perbedaan yang halus, tetapi itu berarti bahwa Anda dapat menggunakannya beberapa kali dalam sesuatu seperti(x, _, _) = ...
, sedangkan mencoba mengikat variabel yang sama beberapa kali akan menjadi kesalahan.Dalam Python
_
dapat diterima. Namun itu dapat bertentangan dengangettext
alias_()
.Konvensi umum lainnya adalah
dummy
,unused
; sendiri atau sebagai awalan.Beberapa alat analisis kode mengetahui konvensi ini dan tidak akan mengeluarkan peringatan variabel yang tidak digunakan:
_
ataudummy
_
,unused
ataudummy
sumber
_
untuk variabel dummy di python akan berbenturan dengan_
nilai yang dikembalikan terakhir. Misalnya, dalam penerjemah, jika Anda melakukannya5*5
pada baris 1; maka pada baris 2_
akan memiliki nilai25
. Namun jika Anda kemudian mengaturx,_ = (3,'not used')
, Anda akan menemukan bahwa_
sekarangnot used
bukan nilai yang dikembalikan terakhir sampai Andadel _
. Anda mungkin tidak boleh menggunakan_
nilai terakhir yang dikembalikan dalam kode nyata; tetapi sering berguna dalam penerjemah ketika mencoba hal baru._
karena nilai yang dikembalikan terakhir hanya berfungsi di shell interaktif.Tergantung pada ekosistem di mana kode ini akan hidup. Jika
_
standar yang diterima untuk menunjukkan "variabel dummy" / "output yang tidak digunakan", maka dengan segala cara, tetaplah menggunakannya. Jika tidak, cari tahu apa dan gunakan itu.Beberapa bahasa pemrograman (mis. Haskell) bahkan memiliki pengidentifikasi 'khusus' ini dibangun ke dalam sintaks mereka untuk tujuan yang Anda sebutkan.
sumber
Hati-hati, _ sudah memiliki makna intrinsik dalam beberapa bahasa
Dengan Python:
Ada juga penyebutan lain dalam PEP 8 (Style Guide for Python Code):
Dalam C #:
Ini umumnya digunakan untuk menandai variabel pribadi yang memiliki properti publik / internal. Tetapi praktik ini pada umumnya dipandang rendah pada hari-hari ini .
Dalam JavaScript:
Ada perpustakaan yang disebut underscore.js yang menggunakan garis bawah sebagai awalan untuk ekstensi prototipe non-standar.
Contoh:
Yang mengarahkan saya ke poin saya. Apa yang salah dengan konvensi variabel placeholder klasik.
Mengapa menggunakan konvensi khusus yang mungkin disalahtafsirkan oleh sebagian orang ketika sudah ada banyak konvensi umum yang sudah tersedia?
sumber
Saya menggunakan "dummy" untuk hal semacam itu. Atau "omong kosong", jika saya hanya menguji sesuatu :) Beri nama variabel Anda untuk menggambarkan apa itu. Jika mereka dummy, variabel yang tidak digunakan, beri nama demikian.
sumber
Saya menganggapnya sebagai latihan yang buruk karena
Anda seharusnya tidak memiliki variabel tak terlihat dalam kode Anda. Jika menurut Anda sebaiknya alasannya mungkin bisa dibahas.
bahasa Go menggunakan kata kunci ini untuk menunjukkan bahwa tidak ada variabel yang menjadi tujuan salah satu dari beberapa pengembalian fungsi. Jika bahasa Anda tidak memiliki banyak pengembalian, itu tidak diperlukan. Konvensi penamaan Anda akan merugikan Anda pada hari Anda akan menggunakan bahasa menggunakan _ sebagai notasi bahasa standar.
(Saya tidak tahu Python: apakah konstruksi ini benar-benar diperlukan?)
sumber
let (a,b,_) = f(x,y,z)
dengan baiklet f(x,y,_) = (g(x),h(x),g(y))
, atau apa pun. - Dan, ya, sering berguna untuk memiliki parameter dummy: bukan sebagai satu-satunya definisi fungsi, tetapi untuk fungsi polimorfik atau yang dengan definisi pola-cocok alternatif, sering kali merupakan hal yang wajar untuk dilakukan.Ini mungkin valid secara sintaksis, dan mungkin OK sebagai bagian dari standar.
Dengan mengatakan itu, itu adalah sesuatu yang saya akan meminta seseorang untuk berubah dalam tinjauan kode. Saya juga tidak akan pernah memasukkannya ke dalam standar pengkodean, dan akan mencoba untuk menghapusnya dari yang sudah ada. Hanya saja lebih sulit dibaca, dan tidak super bermakna.
sumber
Saya pikir itu salah karena:
1) Lebih sulit dilihat karena tidak banyak piksel.
2) Jika ada lebih dari satu
_
, bagaimana Anda tahu yang mana? - atau bahwa pengembang baru telah 'mengikuti aturan' dan mempertahankan penggunaannya dalam lingkup yang sangat lokal?3) Ini adalah praktik yang tidak bermanfaat. Menggunakan nama variabel satu huruf adalah sekolah yang sangat tua (yaitu pendidikan awal saya!). Saya akan melihat mereka ... dan kemudian melihat komentar ditambahkan untuk mengatakan apa yang kode lakukan dan itu praktik buruk di dunia saat ini. Saya menggunakan nama variabel panjang sebanyak mungkin sehingga semua orang, terlepas dari tingkat pemrograman atau keakraban dengan kode bisa "membacanya" hampir seperti bahasa Inggris. Menggunakan 1 nama huruf adalah praktik yang sangat umum dengan kode lama dan dengan programmer lama (sekali lagi, termasuk saya) tetapi itu tidak membuatnya ok.
sumber
_
sudah digunakan dalam lingkup luar; bahwa seseorang kemudian akan dibayangi (atau apa pun bahasa Anda dalam kasus seperti itu), tetapi tidak satupun dari mereka yang benar-benar digunakan.Untuk menghindari tabrakan namespace, dan memungkinkan untuk debugging, kalau-kalau nama variabel adalah satu-satunya petunjuk Anda, mungkin lebih baik untuk menyebutnya "bergabung_ab_unused".
Terinspirasi oleh Birfl.
sumber
Ya, ini adalah praktik buruk karena dua alasan:
sumber
Apa yang Anda coba lakukan adalah kode dalam versi SQL yang lebih bagus yang tidak memiliki masalah memaksa Anda untuk menciptakan nama untuk sesuatu yang tidak berguna.
Garis bawah hampir tidak terlihat, jadi sepertinya Anda menggunakan bahasa itu. Jika hanya spasi putih yang dapat digunakan sebagai pengidentifikasi, itu akan sempurna, bukan?
Tetapi Anda tidak menggunakan bahasa yang berbeda, dan apa yang Anda lakukan bukanlah cara yang bersih untuk membuat ekstensi bahasa.
sumber
Itu tergantung pada bahasanya. Di java , ya ini buruk dan bisa menjadi tren berbahaya untuk ditambahkan ke kode Anda, terutama karena alat yang menggunakan refleksi tidak menangani garis bawah dengan sangat baik, karena mereka berada di luar konvensi penamaan variabel java. Dalam python , ini juga buruk tetapi tidak seburuk itu. Dalam clojure , ini 100% oke, dan pada kenyataannya, itu idiomatis untuk menggunakan _'s sebagai pemegang tempat dalam pernyataan let.
Ingatlah bahwa setiap bahasa memiliki seluruh sintaks dan rangkaian idiomnya sendiri, jadi Anda harus mengevaluasi baik / buruk dalam hal idiom ini, daripada dalam istilah absolut.
sumber
Ini akan buruk di perl, yang menggunakan $ _ (dan kadang-kadang _) sebagai variabel khusus.
Secara umum, saya akan tinggal jauh dari itu hanya karena _ tampaknya menjadi bahasa yang dapat ditentukan. Jika saya melihat kode Anda, saya akan di dokumentasi mencari apa _ itu, sampai saya menyadari itu hanya boneka. Tidak ada yang salah dengan DUMMY, $ DUMMY, terserah.
sumber
Saya akan menghindari garis bawah pada awal vars kecuali Anda yakin mereka tidak cenderung menunjukkan sesuatu yang lain dalam bahasa tertentu atau kerangka kerja yang banyak digunakan. Misalnya, dalam Python, garis bawah ganda cenderung menunjukkan var ajaib. Di JQuery dan pustaka JS lainnya, garis bawah tunggal cenderung mengindikasikan fallback var untuk namespace yang ditimpa. Ini juga merupakan konvensi penamaan populer untuk menyertakan file yang pada gilirannya cenderung membawa ke kode yang menangani menyertakan dalam bentuk var.
sumber