it-swarm-id.com

Konvensi penamaan: camelCase versus underscore_case? apa pendapat anda tentang itu?

Saya telah menggunakan underscore_case selama sekitar 2 tahun dan saya baru-baru ini beralih ke camelCase karena pekerjaan baru (telah menggunakan yang kemudian selama sekitar 2 bulan dan saya masih berpikir underscore_case lebih cocok untuk proyek-proyek besar di mana ada banyak programmer yang terlibat, terutama karena kodenya lebih mudah dibaca).

Sekarang semua orang di tempat kerja menggunakan camelCase karena (begitu kata mereka) kodenya terlihat lebih elegan.

Apa pendapat Anda tentang camelCase atau underscore_case

hal. tolong permisi bahasa Inggris saya yang buruk

Edit

Beberapa pembaruan pertama:

  • platform yang digunakan adalah PHP (tapi saya tidak mengharapkan ketat PHP jawaban terkait platform, siapa pun dapat berbagi pemikiran mereka tentang mana yang akan menjadi yang terbaik untuk digunakan, itu kenapa saya datang ke sini?

  • Saya menggunakan camelCase sama seperti semua orang di tim (sama seperti kebanyakan dari Anda merekomendasikan)

  • kami menggunakan Zend Framework yang juga merekomendasikan camelCase

Beberapa contoh (terkait dengan PHP):

  • Kerangka codeigniter merekomendasikan underscore_case, dan jujur ​​kode lebih mudah dibaca.

  • ZF merekomendasikan camelCase dan saya bukan satu-satunya yang berpikir kode ZF sedikit sulit ditindaklanjuti.

Jadi pertanyaan saya akan diulangi:

Mari kita ambil suatu kasus di mana Anda memiliki platform Foo yang tidak merekomendasikan konvensi penamaan dan itu adalah pilihan ketua tim untuk memilih satu. Anda adalah pemimpin tim itu, mengapa Anda memilih camelCase atau mengapa underscore_case?

hal. terima kasih semuanya atas jawaban Prompt sejauh ini

70
poelinca

Saya setuju bahwa itu tergantung pada bahasa yang Anda gunakan sampai batas tertentu; kode cenderung terlihat lebih rapi ketika nama simbol Anda mengikuti regimen pemformatan yang sama dengan pustaka bawaan dan stok bahasa.

Tapi di mana ada pilihan, saya lebih suka menggarisbawahi untuk kasus unta, karena satu alasan sederhana: Saya menemukan gaya yang lebih mudah dibaca. Berikut ini sebuah contoh: mana yang menurut Anda lebih mudah dibaca? Ini:

aRatherLongSymbolName

atau ini:

a_rather_long_symbol_name

Saya menemukan versi garis bawah lebih mudah dibaca. Otak saya dapat mengabaikan garis bawah dengan lebih mudah daripada mendeteksi batas huruf kecil/huruf besar dalam peti unta, terutama di mana batasnya berada di antara mesin terbang yang terlihat mirip dengan mesin terbang lain dari kotak yang berlawanan, atau angka (I/l, O/0, t/I, dll). Sebagai contoh, variabel boolean ini menyimpan nilai yang menunjukkan apakah Igloo telah dibangun dengan izin perencanaan yang tepat (tidak diragukan lagi kasus penggunaan umum bagi kita semua):

isIllicitIgloo

Saya menemukan versi ini banyak lebih mudah dibaca:

is_illicit_igloo

Mungkin bahkan lebih buruk daripada nama simbol yang sulit dibaca adalah nama simbol yang mudah dibaca. Nama simbol yang baik mendokumentasikan diri, yang bagi saya berarti Anda harus dapat membacanya dan memahami maknanya secara sekilas. (Saya yakin kita semua membaca kode print-out di tempat tidur untuk kesenangan, tetapi kadang-kadang kita juga terburu-buru.) Saya sering menemukan dengan nama simbol case unta bahwa mudah untuk salah membaca mereka dan mendapatkan kesan yang salah dari sebuah semantik simbol.

84
Simon Whitaker

Saya pikir Anda harus menggunakan konvensi penamaan yang diadopsi oleh platform Anda. underscore_case akan terlihat aneh dalam kode C #, seperti camelCase di Ruby =)

97
Alexey Anufriyev

Sejujurnya, itu tidak masalah asalkan semua orang di tim menggunakan skema yang sama. Kemungkinannya adalah satu atau yang lain lebih alami bagi Anda, meskipun kepentingan sebenarnya adalah keterbacaan kode dalam jangka panjang dan kemudian sangat penting bahwa setiap orang mematuhi aturan penamaan yang sama.

20
dafmetal

Berdasarkan balasan, balasan dari John Isaacks:

"jujur ​​kode lebih mudah dibaca" Opini atau fakta?

Saya memutuskan untuk melakukan riset, dan menemukan makalah ini . Apa yang dikatakan sains tentang masalah ini?

  1. Casing unta memiliki probabilitas kebenaran yang lebih besar daripada garis bawah. (Peluang 51,5% lebih tinggi)
  2. Rata-rata, unta membawa lebih lama 0,42 detik , yang merupakan 13,5% lebih lama.
  3. Pelatihan tidak memiliki dampak yang signifikan secara statistik pada bagaimana gaya memengaruhi kebenaran.
  4. Mereka yang memiliki lebih banyak pelatihan lebih cepat pada pengidentifikasi dalam gaya case unta.
  5. Pelatihan dalam satu gaya, berdampak negatif pada waktu mencari untuk gaya lainnya.

Di posting blog saya pada subjek saya meninjau makalah ilmiah, dan membuat kesimpulan berikut.

Hanya kelambatan kasing kasus unta (2) benar-benar relevan untuk pemrograman, mengabaikan titik-titik lain sebagai tidak relevan karena IDE modern dan mayoritas pengguna camelCase dalam penelitian ini. Diskusi (bersama dengan jajak pendapat) dapat ditemukan di posting blog.

Saya ingin tahu bagaimana artikel ini dapat mengubah opini orang. :)

20
Steven Jeuris

Salin Orang Tercerdas

Dalam hal bahasa pemrograman, salin gaya pengembang bahasa.

Misalnya saya kode C persis seperti yang dilakukan di K&R.

Lalu ketika ada orang yang mencoba memulai percakapan gaya koding yang membosankan, saya dapat memberi tahu mereka "bicarakan dengan Dennis Ritche dan beri tahu saya apa yang dia katakan."

11
Mark Harrison

Secara umum, saya lebih suka camelCase. Namun, itu karena sebagian besar karir saya, saya telah bekerja dalam bahasa dan lingkungan di mana panduan gaya biasanya merekomendasikan camelCase. (Java, ECMAScript, C++). Anda, menjadi PHP orang, cenderung memiliki preferensi yang berlawanan.

Yang mengatakan, ketika Anda melampaui tigaOrfourWords, atau jika Anda menggunakan inisialisasi seperti XmlForExample, itu berhenti menjadi sangat mudah dibaca.

Itulah sebabnya emacs memberi kita mode kacamata.

10
Paul Butcher

camelCase

Ini adalah salah satu dari sedikit tempat saya akan selalu memilih 'tipe-kemampuan' daripada keterbacaan. CamelCase lebih mudah untuk diketik, dan menjadi lebih baik di jari saya akan menang dibandingkan dengan sedikit kemudahan untuk dibaca.

dengan asumsi tentu saja bahwa proyek tidak membangun basis kode yang ada dengan standar yang berbeda.

8
AShelly

Ini adalah pertanyaan yang menarik, saya telah memikirkan ini berulang kali. Tapi saya kira tidak ada jawaban yang pasti.

Mengikuti konvensi "budaya" itu pilihan yang baik. "Budaya" dalam hal ini berarti konvensi yang didirikan di tim/perusahaan dan pada dasarnya mereka membawa konvensi bahasa/platform juga. Ini membantu orang lain untuk membaca/menggunakan kode Anda dengan mudah dan tidak memerlukan upaya dan waktu tambahan untuk masuk ke cara memahami kode Anda.

Terkadang menarik untuk membatalkan notasi yang diterima. Salah satu proyek kecil saya (di Python) saya menggunakan underscored_names untuk fungsi utilitas/metode "protected", dan gaya Java methodNames untuk metode. Tim saya senang dengan itu :)

7
duros

Tergantung pada bahasa pemrograman.

Saya mempertimbangkan untuk menggunakan kasing di kapal yang sama apakah menggunakan notasi Hongaria atau tidak:

  • Python: underscore_case, tidak ada notasi Hungaria
  • C++: camelCase, notasi Hongaria
6
Lionel

Kedua!

Saya melakukan banyak pengembangan di CakePHP, dan saya menggunakan CamelCase atau $underscored_vars, Dengan cara berikut (bahkan di luar Proyek CakePHP):

  1. nama file - /lowercased_underscored.php Khas, tetapi layak disebutkan.
  2. kelas - class CamelCase extends ParentObject. Perhatikan bahwa, ketika menggunakan CamelCase, karakter awal bukan huruf kecil. Saya menemukan camelCase terlihat benar-benar aneh.
  3. variabel - $are_variables_underscored === TRUE;
  4. variabel yang menyimpan instance - $CamelCase = new CamelCase();
  5. kunci larik - $collection['underscored_keys'];
  6. konstanta - Saya pikir semua orang bisa setuju bahwa konstanta harus ALL_CAPS_AND_UNDERSCORED.
  7. metode - $CamelCase->foo_method_underscored();
  8. metode statis - CamelCase::just_like_regular_methods();
6
Stephen

Saya pribadi lebih suka underscore_case karena saya merasa lebih mudah dibaca, tetapi setuju dengan penjawab lain yang menunjukkan bahwa konsistensi dengan basis kode yang ada jauh lebih penting.

Namun, saya memiliki contoh tandingan untuk mereka yang mengatakan "ikuti konvensi bahasa Anda dan perpustakaannya".

Di masa lalu kami menulis kode C pada Windows menggunakan underscore_case, dan disebut fungsi PascalCase Win32:

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

Perbedaan visual antara nama fungsi kami dan nama fungsi Microsoft adalah bantuan daripada halangan, seperti yang terlihat jelas ketika kode masuk ke "sistem lahan".

Selain itu, saya dapat mengubah aturan penyorotan sintaksis editor saya untuk menampilkannya dalam warna yang berbeda, yang memberikan petunjuk visual lebih lanjut ketika mencoba memahami bagian kode yang tidak dikenal (atau bahkan milik saya).

5
Paul Stephenson

Saya benar-benar menyukai Dylan yang hanya biasa saja, karena mereka mudah diketik dan mudah dibaca.

Suka

result-code := write-buffer(file-stream, some-string)

Tapi saya kira karena bahasa ini cukup tidak jelas, ini semacam di luar topik ... :(

5
Kosta

Saya diajari menggunakan camelCase di universitas. Saya telah menggunakan beberapa konvensi yang berbeda selama beberapa tahun terakhir tetapi lebih suka camelCase daripada yang lainnya. Saya rasa saya ingat pernah membaca di suatu tempat bahwa camelCase sebenarnya yang paling mudah dibaca dan dimengerti.

4
Ross

Secara pribadi, saya lebih suka camelCase, tetapi dalam beberapa font saya pikir garis bawah lebih mudah dibaca.

Saya menyarankan bahwa jika Anda perlu menggunakan awalan untuk membedakan set variabel, Anda harus menggunakan bahasa yang memungkinkan Anda membuat ruang nama atau objek atau sesuatu untuk menyimpan informasi itu.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Demikian juga, jika Anda perlu membedakan jenis, mengapa tidak menggunakan bahasa yang memungkinkan mereka?

var intThingy = 7; // :(

int thingy = 7;    // :)

Setelah Anda memiliki yang lurus, dan Anda tidak hanya menggunakan nama sebagai meta-data, maka Anda tidak akan memiliki nama yang cukup panjang sehingga sangat penting apakah Anda lebih suka penekanan tombol ekstra atau tidak.

4
Kevin Cantu

Seperti kebanyakan orang sebutkan - Gunakan standar yang ada. Jika ini adalah proyek baru, gunakan standar untuk bahasa dan kerangka kerja yang akan Anda gunakan.

Dan jangan bingung, ini bukan tentang keterbacaan (yang subjektif), ini tentang menjadi konsisten dan profesional. Siapa pun yang telah bekerja dalam basis kode dengan banyak 'standar' akan mengerti.

4
Colin Goudie

Terkadang saya menggunakan campuran: module_FunctionName. Semua fungsi (non-statis) dalam modul saya mulai dengan singkatan modul.

Misalnya fungsi untuk mengirim konten buffer di bus I2C:

i2c_BufferSend()

Alternatif i2c_buffer_send tidak menunjukkan pemisahan yang cukup besar antara awalan dan nama fungsi. i2cBufferSend terlalu banyak bercampur dalam awalan (ada cukup banyak fungsi I2C dalam modul ini).

i2c_Buffer_send mungkin bisa menjadi alternatif.

Jawaban saya adalah Anda beradaptasi dengan apa yang paling cocok untuk proyek Anda (bahasa Anda, arsitektur SW Anda, ...), dan saya ingin menunjukkan bahwa memadukan gaya-gaya ini mungkin berguna.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

4
Gauthier

Untuk bahasa pemrograman yang saya gunakan, seperti Java, Python, C++, saya sudah mengadopsi format yang jelas:

  • ClassNamesArePascalCase
  • methodNamesAreCamalCase
  • variable_names_are_underscore
  • CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Ini memungkinkan saya untuk segera mengetahui apa yang sedang saya hadapi. Saya telah menemukan bahwa berguna untuk memelihara untuk diri saya sendiri, dan itu harus mudah diikuti untuk orang lain yang membaca kode. Saya pikir konsistensi yang disebutkan adalah yang paling penting. Jadi saya menemukan format saya cukup sederhana untuk dipertahankan, sambil memberikan perbedaan yang jelas antara jenis nama. Saya bisa membayangkan interface_Names_Are_Like_This dan Abstract_Classes_Are_Like_This sebagai ekstensi yang mungkin, tetapi tampaknya lebih rumit untuk diikuti dan mungkin tidak ada perbedaan yang berguna untuk dibuat.

Saya juga menemukan itu berguna untuk menjadi ketat dan memberi nama hal-hal di PascalCase seperti parser HTML sebagai HtmlParser, bukan HTMLParser atau HTMLparser. Karena saya percaya akan lebih mudah untuk mengingat aturan yang ketat dan membuat batas-batas Word lebih jelas (sayangnya hal itu membutuhkan kesalahan ejaan seperti HTML atau SQL). Demikian pula dengan camelCase, htmlParserMethod, bukan HTMLParserMethod atau HTMLparserMethod.

PEMBARUAN :

Sejak saya menemukan digunakan dalam memperluas aturan-aturan ini untuk memasukkan variabel pribadi. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

Di Jawa, ini berarti bahwa bidang pribadi menurut definisi dalam ruang nama yang berbeda dari variabel lokal, yang berarti Anda dapat melewati this. di bidang pribadi. Format lain saya telah melihat awalan dengan "m", tetapi format itu juga menggunakan camelCase untuk nama variabel. Ini juga memungkinkan saya untuk membuat perbedaan antara bidang yang seharusnya hanya diakses secara internal oleh kelas (dan membuatnya super jelas ketika itu terjadi di luar kelas object._field_x menonjol).

2
Dandre Allison

Pada awalnya, saya setuju dengan dafmetal. Sangat penting, bahwa Anda tidak mencampur gaya pemrograman yang berbeda. Melakukan ini dalam satu dan file yang sama adalah yang terburuk yang dapat Anda lakukan IMHO. Di berbagai file, itu mengganggu, tetapi tidak fatal.

Hal berikutnya yang harus Anda lakukan, adalah pada aturan penamaan yang populer untuk bahasa yang Anda tulis. Kode C++ saya untuk instnace, akan terlihat berbeda dari sesuatu untuk Python jelas (PEP8 adalah panduan yang bagus di sini)

Anda juga dapat menggunakan konvensi penamaan yang berbeda untuk merujuk pada hal-hal yang berbeda, sebanyak mungkin Anda menggunakan UPPER_CASE untuk konstanta (ini hanya berlaku untuk bahasa tertentu saja), Anda dapat menggunakan gaya ini untuk nama variabel lokal, sedangkan Anda menggunakan camelCase sebagai contoh/anggota variabel. Ini mungkin tidak diperlukan ketika Anda memiliki hal-hal seperti self atau this namun.

Memperbarui

Mari kita ambil suatu kasus di mana Anda memiliki platform penyihir Foo tidak merekomendasikan konvensi penamaan dan itu adalah pilihan ketua tim untuk memilih satu. Anda adalah pemimpin tim itu, mengapa Anda memilih camelCase atau mengapa underscore_case.

Tidak ada keuntungan untuk yang satu lebih dari yang lain. Hal ini sangat subyektif dan sekali disetujui, tidak akan ada bedanya. Selalu ada perang yang saling terkait tentang hal-hal kecil ini. Tapi begitu Anda sudah menyesuaikan diri dengan baik, diskusi tampaknya sepenuhnya berlebihan.

Mengutip Alex Martelli tentang hal yang sangat mirip:

Tentu saja, saya merasa lelah, di Ruby, mengetik "akhir" konyol di akhir setiap blok (bukan hanya melemahkan) - tapi kemudian saya bisa menghindari mengetik yang sama-sama konyol ':' yang Python membutuhkan di mulai dari setiap blok, jadi itu hampir bersih :-). Perbedaan sintaksis lain seperti '@foo' versus 'self.foo', atau signifikansi huruf yang lebih tinggi dalam Ruby vs Python, benar-benar sama tidak relevannya bagi saya.

Yang lain tidak diragukan lagi mendasarkan pilihan mereka pada bahasa pemrograman hanya pada masalah seperti itu, dan mereka menghasilkan perdebatan terpanas - tetapi bagi saya itu hanya contoh dari salah satu Hukum Parkinson dalam tindakan ( jumlah pada debat pada suatu masalah berbanding terbalik dengan kepentingan aktual masalah itu ).

Sumber

Jika Anda adalah pemimpin tim, Anda hanya pergi dengan satu. Karena yang satu tidak memiliki kelebihan di atas yang lain, Anda bisa melempar dadu atau memilih yang Anda sukai.

2
phant0m

Saya membaca beberapa tahun yang lalu bahwa programmer yang tidak berbicara bahasa Inggris sebagai bahasa pertama cenderung menemukan case garis bawah lebih mudah untuk memahami case unta itu - tetapi saya tidak dapat menemukan referensi, dan saya tidak tahu apakah itu benar.

2
Ed Harper

Jika itu tergantung pada saya, saya tidak akan memaksakan atau mengisyaratkan penggunaan gaya tertentu karena, sebagai programmer, kita dapat membaca simbol IfItIsInCamelCase atau in_underscore_space atau bahkan di_SomeOtherStyle dan mengerti apa artinya. Harus menghabiskan sedikit waktu untuk menguraikan simbol bukanlah biaya besar dalam skema hal-hal besar.

Sekarang, argumen utama untuk konvensi saya kira adalah Anda tahu di muka apa format fungsi/nama variabel dan tidak perlu mencarinya - apakah itu LoadXMLFile, loadXMLFile, LoadXmlFile, LoadXmlFile, load_xml_file? Sekarang, saya akan melawan argumen itu dengan mengatakan "Dapatkan IDE yang mendukung penyelesaian otomatis gaya intellisense!" (Meskipun tidak selalu mungkin).

Pada akhirnya, tidak masalah gaya apa yang Anda gunakan karena kompiler/penerjemah tidak terlalu peduli. Yang penting adalah bahwa nama itu berguna:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Tiga gaya berbeda, tetapi Anda tahu persis apa yang dilakukan masing-masing.

1
Skizz

Saya cenderung lebih suka camelCase karena alasan konyol bahwa saya melakukan sebagian besar pengembangan saya di Eclipse (Untuk Java, PHP dan JavaScript), dan ketika saya Ctrl+ atau Ctrl+ melalui kata-kata, itu benar-benar berhenti di batas camelCase.

I.e .: myIntVariable akan diperlakukan oleh Eclipse sebagai 3 kata saat Ctrl+← →melaluinya.

Saya tahu ini adalah keanehan aneh, tetapi saya lebih suka bisa mengedit kata tengah dalam nama camelCase.

0
Bassam

Mungkin terlihat konyol, tapi saya tidak suka garis bawah karena garis bawahnya tipis, dan bersembunyi di banyak teks baris dan saya melewatkannya. Juga, di beberapa (banyak) editor teks dan/atau lingkungan dev, ketika Anda mengklik dua kali pada nama token untuk menyorotnya sehingga untuk menyalin atau menarik dan menjatuhkannya, sistem tidak akan menyorot seluruh token, hanya menyoroti satu bagian token, antara garis bawah yang berdekatan. Itu membuatku gila.

0
Charles Bretana