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

Saya telah menggunakan underscore_case selama sekitar 2 tahun dan saya baru saja 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

ps mohon permisi bahasa Inggris saya yang buruk

Sunting

Beberapa pembaruan pertama:

• platform yang digunakan adalah PHP (tapi saya tidak mengharapkan jawaban terkait platform PHP yang ketat, siapa pun dapat berbagi pemikiran mereka tentang yang terbaik untuk digunakan, itu sebabnya saya datang ke sini sejak awal)

• 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?

ps, terima kasih semuanya atas jawaban yang cepat sejauh ini

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 kasus unta, untuk satu alasan sederhana: Saya menemukan gaya yang lebih mudah dibaca. 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 jauh lebih mudah daripada yang dapat mendeteksi batas-batas huruf kecil / huruf besar dalam kasus unta, terutama di mana batas-batas antara mesin terbang yang terlihat mirip dengan mesin terbang lain dari kasus sebaliknya, atau angka ( I/l, O/0, t/I, dll). Misalnya, 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 jauh 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.

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

Sejujurnya, itu tidak masalah asalkan semua orang di tim menggunakan skema yang sama. Kemungkinannya 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.

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 kemungkinan kebenaran yang lebih besar daripada garis bawah. (Peluang 51,5% lebih tinggi)
2. Rata-rata, unta membutuhkan waktu 0,42 detik lebih lama , yaitu 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 kasus unta.
5. Pelatihan dalam satu gaya, berdampak negatif pada waktu mencari gaya lain.

Dalam posting blog saya tentang subjek saya meninjau makalah ilmiah, dan membuat kesimpulan berikut.

Hanya lambatnya kasus unta (2) yang benar-benar relevan untuk pemrograman, menolak poin-poin 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. :)

Salin Cowok Paling Cerdas

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."

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, sebagai orang PHP, 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.

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 saya baca.

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

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 dalam cara memahami kode Anda.

Terkadang menarik untuk membatalkan notasi yang diterima. Salah satu proyek kecil saya (pada Python) saya gunakan underscored_namesuntuk fungsi utilitas / metode "protected", dan gaya Java methodNamesuntuk metode. Tim saya senang dengan itu :)

Tergantung pada bahasa pemrograman.

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

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

Kedua!

Saya melakukan banyak pengembangan di CakePHP, dan saya menggunakan salah satu CamelCaseatau $underscored_vars, dengan cara berikut (bahkan di luar Proyek CakePHP):

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

Saya pribadi lebih suka underscore_casekarena 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 PascalCasefungsi 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).

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 ... :(

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.

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 berbagai 'standar' yang terjadi akan mengerti.

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_sendtidak menunjukkan pemisahan yang cukup besar antara awalan dan nama fungsi. i2cBufferSendterlalu 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.

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 yang sangat penting apakah Anda lebih suka penekanan tombol ekstra atau tidak.

Pada awalnya, saya setuju dengan dafmetal. Ini adalah yang paling 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 selanjutnya 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 selfatau thisbagaimanapun.

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, saya merasa lelah, di Ruby, mengetik "akhir" konyol di akhir setiap blok (bukan hanya tanpa penghinaan) - tapi kemudian saya bisa menghindari mengetik yang sama-sama konyol ':' yang diminta oleh Python di yang start dari setiap blok, sehingga hampir mencuci :-). Perbedaan sintaksis lain seperti '@foo' versus 'self.foo', atau signifikansi case yang lebih tinggi di 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 tentang suatu masalah berbanding terbalik dengan masalah tersebut). kepentingan aktual ).

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.

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

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 merasa berguna untuk bersikap 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 ketat dan menjaga batas kata menjadi lebih jelas (sayangnya itu membutuhkan hal-hal yang salah mengeja 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.bidang pribadi. Format lain saya pernah melihat awalan dengan " m", tetapi format itu juga menggunakan camelCase untuk nama variabel. Ini juga memungkinkan saya untuk membuat perbedaan antara bidang yang hanya dapat diakses secara internal oleh kelas (dan membuatnya sangat jelas ketika itu terjadi di luar kelas object._field_xmenonjol).

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 memahami 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 pelengkapan otomatis gaya intellisense!" (tidak selalu mungkin).

Pada akhirnya, tidak masalah gaya apa yang Anda gunakan karena kompiler / juru bahasa 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.

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 pengembang, 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.

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.

Yaitu: myIntVariableakan diperlakukan oleh Eclipse sebagai 3 kata-kata ketika Ctrl+ ← →'ing melalui itu.

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