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


70

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


6
"jujur ​​kode lebih mudah dibaca" Opini atau fakta?
JD Isaacks

9
IThinkTheyAreBothAboutTheSame but_i_think_mixing_them_is_pretty_bad.
dietbuddha

7
@dietbuddha: Saya baru saja membaca 'but_i_think_mixing_them_is_pretty_bad' jauh lebih cepat daripada 'IThinkTheyAreBothAboutAboutTheSame'. Saya cukup yakin itu bisa dibuktikan secara ilmiah. :)
Steven Jeuris

@John Isaacks: Saya sedih untuk melaporkan (sebagai penganjur huruf kecil), bahwa sebuah penelitian menyimpulkan bahwa "selubung unta mengarah ke akurasi yang lebih tinggi di antara semua mata pelajaran tanpa memandang pelatihan" .
Steven Jeuris

IWonderWhetherReadingEnglishWrittenInOneStyleVersusAnotherMakesMuchDifference. InTheEnd, JIKA TIDAK PERNAH AKAN SANGAT SANGAT BAIK DENGAN BAIK. It_screws_horribly_with_line_length_and_makes_even_the_simplest_thing_complicated. I_wonder_whether_there_would_be_language_support_in_the_future_for_quoted_variable_names. "Menurut saya ini jauh lebih masuk akal daripada camelCase atau underscore_separators".
Christopher Mahan

Jawaban:


84

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.


25
Satu masalah dengan garis bawah: kegunaan. Untuk sebagian besar keyboard (Eropa), mengetikkan tanda garis bawah memerlukan menahan tombol SHIFT. Anda perlu melakukan itu untuk camelCase juga, tapi saya dapat dengan nyaman menahan SHIFT dengan pinky dan mengetikkan huruf apa pun - tetapi karena tombol garis bawah tepat di sebelah tombol SHIFT, menekan keduanya pada saat yang sama agak canggung dan mengganggu aliran mengetik.
LearnCocos2D

11
Untuk yang pertama, saya menemukan camelCase lebih mudah dibaca - meskipun yang terakhir jelas berbeda.
Phoshi

19
Ini memang tergantung pada apa yang biasa Anda lakukan. Saya menemukan camelCases lebih mudah untuk dibaca, dan selain itu, mereka lebih pendek dari nama garis bawah setara.
Joonas Pulakka

17
Aku benci mengetik garis bawah.
EpsilonVector

6
Poin "kegunaan" tidak relevan untuk ini. Kode biasanya ditulis hanya satu kali oleh satu orang, tetapi katakanlah dalam urutan 1-10 kali akuntansi untuk beberapa pengeditan dan pemrograman pasangan potensial. Tetapi kode biasanya dibaca selusin / ratusan / ribuan kali oleh satu atau berpotensi banyak orang. Dengan demikian membuat kode mudah dibaca adalah beberapa besaran lebih penting daripada memiliki kode yang mudah ditulis.
hlovdal

97

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


23
Konsistensi adalah kuncinya. Apakah Anda setuju dengan konvensi setempat atau tidak, Anda akan membuat waktu Anda sendiri lebih mudah (dan semua orang lain) dengan konsisten. (Kecuali jika konvensi lokal itu sendiri tidak konsisten.) Selain itu, keterbacaan sebagian besar adalah argumen yang salah: cukup baca kode dan Anda akan menemukan ada sedikit perbedaan kecuali Anda memutuskan itu tidak dapat dibaca.
Richard

1
Sangat setuju. Saya hanya berpikir bahwa lebih baik menggunakan konvensi platform daripada yang khusus, karena misalnya orang baru dalam tim akan merasa lebih nyaman dengannya.
Alexey Anufriyev

2
Tetapi celakalah bagi kita yang bekerja di dua platform dengan dua konvensi, di mana beberapa lebih suka dan beberapa lebih suka yang lain!
Michael K

Jika platform memiliki 2 konvensi, saya akan meminta semua anggota tim untuk memilih konvensi yang mereka sukai =)
Alexey Anufriyev

20

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.


Anda benar-benar benar, namun saya mencoba mencari tahu pendapat orang tentang penyihir akan lebih baik untuk digunakan (katakanlah untuk seluruh tim), dan mengapa ... sementara saya mengerti bahwa beberapa orang mungkin hanya terbiasa dengan konvensi atau yang lain lebih alami dengan yang lain.
poelinca

20

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


3
Tentu saja, Anda mengabaikan semua poin lainnya karena preferensi Anda untuk garis bawah dan poin lainnya tidak membantu kasus Anda ...
Charles Boyung

2
@ Charles: Ya dan tidak, IMHO saya membuat argumen yang bagus mengapa mereka dapat diabaikan, dan beberapa dari mereka bahkan dibahas sebagai masalah oleh kertas itu sendiri. Sebuah kertas tindak lanjut menyelidiki beberapa masalah dari makalah ini , dan hasilnya pro-garis bawah.
Steven Jeuris

11

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


12
Yang asli tidak selalu yang terbaik. Ada banyak praktik buruk dalam buku Injil K&R tentang C. Sebelum ini memulai perang api ... baca beberapa rekomendasi MISRA.
cepat,

10
Jangan lupa, K&R ditulis ketika tidak ada GUI-IDE. Sebagian besar pekerjaan dilakukan pada terminal karakter 80x25, sehingga ruang layar berada pada tingkat premium, if (...) {menghemat garis! Saat ini, ada lebih banyak ruang layar - apakah K&R akan berbeda jika ditulis hari ini dengan IDE GUI hi-res dan beberapa pengaturan monitor?
Skizz

3
Ya, tetapi ketika seseorang mengatakan mereka kode C seperti K&R, mereka mendapat alat peraga karena sekolah tua.
Christopher Mahan

3
@quickly_now, bawa itu dengan Dennis Ritchie dan beri tahu saya apa yang dia katakan!
Mark Harrison

Saya mengadopsi banyak format dari MS: _internalToClassHanya, dapat diaksesByGetter, PublicVariable.
IAbtract

10

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.


2
+1 untuk membuat saya menemukan mode kacamata! Saya baru saja mengujinya pada file kode yang menggunakan camelCase, dan perhatikan bagaimana itu segera mulai terlihat lebih baik (perakitan dengan banyak label di camelCase).
Gauthier

Oke, apa itu mode kacamata?
Marcie


8

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.


Saya tidak setuju dengan itu, Anda hanya menulis kode sekali, tetapi Anda harus membacanya berulang kali sesudahnya
Roman Pekar

7

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 :)


6

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

8
@Kevin Cantu: Sebenarnya nama Javascript ada di PascalCase daripada camelCase ...
Guffa

1
@Guffa: touché!
Kevin Cantu

2
@Kevin Cantu: di JavaScript: XMLHttpRequest<- Saya benci nama ini dengan penuh gairah.
Thanatos

1
hipotetisalasanToNukeRedmond.push (XMLHttpRequest)
Kevin Cantu

4
@ Lionel: Sebenarnya notasi Hungaria hampir tidak pernah digunakan dalam C ++, karena C ++ sudah memeriksa jenis Anda. Ini lebih dari artefak sejarah daripada yang lainnya.
Di silico

6

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();

3
harus setuju dengan Anda, memiliki karakter pertama menjadi huruf kecil membuatku gila! Saya benci camelCase dengan penuh gairah.
HLGEM

Di Jawa di mana nama biasanya camelCased nama kelas sebenarnya dimulai dengan huruf kapital. Ini untuk membedakan mereka dari nama metode.
James P.

5

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


5

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


3
Saya juga lelah menekan shift untuk mengetik garis bawah.
Gauthier

8
Biasanya ini tidak mungkin untuk nama variabel, karena "-" biasanya berarti minus.
Eric Wilson

4

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
baik itu tidak mudah karena Anda membaca di suatu tempat, itu lebih mudah karena itu yang pertama Anda bekerja dengan dan terutama karena Anda lebih terbiasa, misalnya saya lebih nyaman dengan underscore_case.
poelinca

1
seperti yang saya baca bahwa penelitian telah dilakukan dan ternyata lebih baik ..
Ross

4

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.


4

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.


1
Memberi +1 untuk 2 baris terakhir, namun saya tidak menyarankan Anda menggabungkan konvensi penamaan, Anda harus tetap menggunakan yang satu atau yang lain.
poelinca

Selama konvensi ini didefinisikan dengan baik (awalan + garis bawah + PascalCase) ...
Gauthier

Saya suka menggunakan garis bawah untuk memisahkan bagian-bagian dari nama yang memiliki tujuan yang terpisah secara semantik, terutama jika kesamaan pada kedua setengahnya mungkin signifikan. Misalnya, rutinitas Motor1_Start(), Motor2_Start(), Motor1_Stop()dan Motor2_Stop()memiliki hubungan yang mungkin kurang jelas tanpa garis bawah.
supercat

4

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.


1
Salah satu alasan untuk menggunakan camelCase atau underscore_case adalah agar saya tidak perlu menemukan definisi objek untuk mengetahui apa itu.
Joshua Shane Liberman

2

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.


2

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.


2

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


1

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.


1
Saya mohon berbeda, penampilan sumber itu penting. Lihat "The windows pragmatic programmer" tentang teori windows yang rusak. Memvariasikan konvensi penamaan membuat penampilan lebih buruk. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
Gauthier

1
@ Gauthier: Walaupun saya setuju dengan ide 'broken window', saya tidak berpikir kapitalisasi simbol merupakan 'broken window'. Tentu saja meletakkan kode sembarangan, dan proyek saya saat ini tentu memiliki banyak hal yang saya coba rapikan kapan pun saya bisa.
Skizz

Saya setuju. Saya bisa membaca ketiganya dengan baik. Itu tidak masalah. Saya hanya menggunakan file apa pun yang digunakan, lalu apa pun yang diusulkan bahasa (python) dan kemudian apa pun yang saya rasa proyek akan dilayani dengan baik. (Dulu saya memprogram dalam bahasa gwbasic, dan itu semua adalah topi - hari tua yang indah!)
Christopher Mahan

0

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.