Saya ragu tentang CamelCase. Andaikan Anda memiliki akronim ini:Unesco = United Nations Educational, Scientific and Cultural Organization.

Anda harus menulis: unitedNationsEducationalScientificAndCulturalOrganization

Tetapi bagaimana jika Anda perlu menulis akronim? Sesuatu seperti:

getUnescoProperties();

Apakah benar menulis seperti ini? getUnescoProperties() OR getUNESCOProperties();

Beberapa pedoman yang telah ditulis Microsoft camelCaseadalah:

Saat menggunakan akronim, gunakan case Pascal atau camel untuk akronim yang panjangnya lebih dari dua karakter. Misalnya, gunakan HtmlButtonatau htmlButton. Namun, Anda harus menggunakan huruf besar akronim yang hanya terdiri dari dua karakter, seperti System.IObukan System.Io.

Jangan gunakan singkatan pada pengidentifikasi atau nama parameter. Jika Anda harus menggunakan singkatan, gunakan case unta untuk singkatan yang terdiri dari lebih dari dua karakter, bahkan jika ini bertentangan dengan singkatan standar dari kata tersebut.

Menyimpulkan:

• Saat Anda menggunakan singkatan atau akronim yang panjangnya dua karakter, tutup semuanya;

• Ketika akronim lebih panjang dari dua karakter, gunakan huruf kapital untuk karakter pertama.

Jadi, dalam kasus spesifik Anda, getUnescoProperties()sudah benar.

Ada kritik sah terhadap saran Microsoft dari jawaban yang diterima.

• Perlakuan tidak konsisten dari akronim / inisialisasi tergantung pada jumlah karakter:
  • playerIDvs playerIdvs playerIdentifier.
• Pertanyaan apakah akronim dua huruf masih harus dikapitalisasi jika muncul pada awal pengidentifikasi:
  • USTaxes vs. usTaxes
• Kesulitan dalam membedakan beberapa akronim:
  • yaitu USIDvs usId(atau parseDBMXMLdalam contoh Wikipedia).

Jadi saya akan memposting jawaban ini sebagai alternatif untuk jawaban yang diterima. Semua akronim harus diperlakukan secara konsisten; akronim harus diperlakukan seperti kata lain. Mengutip Wikipedia :

... beberapa programmer lebih suka memperlakukan singkatan seolah-olah itu adalah kata-kata kecil ...

Jadi ulang: pertanyaan OP, saya setuju dengan jawaban yang diterima; ini benar:getUnescoProperties()

Tetapi saya pikir saya akan mencapai kesimpulan yang berbeda dalam contoh-contoh ini:

• US Taxes → usTaxes
• Player ID → playerId

Jadi pilih jawaban ini jika Anda berpikir akronim dua huruf harus diperlakukan seperti akronim lainnya.

Camel Case adalah sebuah konvensi, bukan spesifikasi. Jadi saya kira aturan opini populer.

( EDIT: Menghapus saran ini bahwa suara harus memutuskan masalah ini; seperti yang dikatakan @Brian David; Stack Overflow bukan "kontes popularitas", dan pertanyaan ini ditutup sebagai "berdasarkan opini")

Meskipun banyak yang lebih suka memperlakukan akronim seperti kata lain, praktik yang lebih umum adalah menempatkan akronim dalam huruf besar semua (meskipun mengarah pada "kekejian")

• Lihat "EDXML" dalam skema XML ini
• Lihat "SFAS158" dalam skema XBRL ini

Sumber Daya Lainnya:

• Perhatikan beberapa orang membedakan antara singkatan dan akronim
• Catatan Pedoman Microsoft membedakan antara akronim dua karakter, dan "akronim lebih dari dua karakter"
• Perhatikan beberapa orang merekomendasikan untuk menghindari singkatan / akronim sekaligus
• Perhatikan beberapa orang merekomendasikan untuk menghindari CamelCase / PascalCase sama sekali
• Perhatikan beberapa orang membedakan antara "konsistensi" sebagai "aturan yang tampaknya tidak konsisten secara internal" (yaitu memperlakukan akronim dua karakter berbeda dari akronim tiga karakter); beberapa orang mendefinisikan "konsistensi" sebagai "menerapkan aturan yang sama secara konsisten" (walaupun aturan tersebut secara internal tidak konsisten)
• Pedoman Desain Kerangka Kerja
• Pedoman Microsoft

Pertama, saya harus mengklarifikasi bahwa saya bukan penutur asli bahasa Inggris , jadi klaim saya tentang tata bahasa Inggris bisa saja salah. Jika Anda menemukan kesalahan seperti itu, beri tahu saya, dan saya akan sangat berterima kasih.

Praktik terbaik untuk akronim adalah menghindari akronim sebanyak mungkin. Bagaimanapun, ini tidak terjadi karena akronim UNESCOlebih akrab daripada nama lengkap UnitedNationsEducationalScientificAndCulturalOrganization.

Kemudian, saya pikir UNESCOlebih masuk akal daripada Unescokarena hanya lebih dekat dengan bentuk kehidupan nyata sehingga lebih akrab. Saya mengalami kesulitan untuk mencari tahu apa arti kata itu Unescosebenarnya.

Sebagai contoh lain, pikirkan Arc. Ini terdengar seperti kurva di sekitar lingkaran, tetapi di Rust, ini artinya Atomically Reference Counted. Jika ditulis seperti itu ARC, setidaknya pembaca akan mengenali bahwa kata itu adalah akronim dari sesuatu yang lain dan bukan semacam kurva.

Program modern ditulis terutama untuk pembaca manusia. Kemudian aturan penamaan tersebut harus ditetapkan untuk keterbacaan manusia daripada pemrosesan mesin atau analisis.

Dalam perspektif ini, kami kehilangan beberapa keterbacaan dengan menggunakan Unescolebih UNESCOsambil tidak mendapatkan apa-apa.

Dan untuk kasus lain, saya pikir hanya mengikuti aturan akronim (atau konvensi) bahasa Inggris yang sederhana sudah cukup untuk sebagian besar kasus agar mudah dibaca .

Untuk mengonversi ke CamelCase, ada juga algoritma Camel case deterministic Google (hampir) :

Dimulai dengan bentuk prosa nama:

1. Konversikan frasa menjadi ASCII polos dan hapus apostrof. Misalnya, "Algoritma Müller" mungkin menjadi "Algoritma Mueller".
2. Bagilah hasil ini menjadi kata-kata, pisahkan dengan spasi dan tanda baca yang tersisa (biasanya tanda hubung).
   1. Direkomendasikan: jika kata apa pun sudah memiliki penampilan kasus unta konvensional dalam penggunaan umum, pisahkan ini menjadi bagian-bagian penyusunnya (misalnya, "AdWords" menjadi "kata-kata iklan"). Perhatikan bahwa kata seperti "iOS" tidak benar-benar dalam huruf unta; itu menentang konvensi apa pun, jadi rekomendasi ini tidak berlaku.
3. Sekarang huruf kecil semuanya (termasuk akronim), maka huruf besar hanya karakter pertama dari:
   1. ... setiap kata, untuk menghasilkan kotak unta atas, atau
   2. ... setiap kata kecuali yang pertama, untuk menghasilkan kasing unta yang lebih rendah
4. Akhirnya, gabungkan semua kata menjadi satu pengidentifikasi.

Perhatikan bahwa selubung kata-kata aslinya hampir seluruhnya diabaikan.

Dalam contoh berikut, "Permintaan XML HTTP" diubah dengan benar ke XmlHttpRequest, XMLHTTPRequest salah.

getUnescoProperties() harus menjadi solusi terbaik ...

Bila mungkin ikuti saja yang murni camelCase, saat Anda memiliki akronim, biarkan saja huruf besar bila mungkin sebaliknya camelCase.

Umumnya dalam variabel pemrograman OO harus dimulai dengan huruf kecil ( lowerCamelCase) dan kelas harus dimulai dengan huruf besar ( UpperCamelCase).

Jika ragu, pergilah murni camelCase;)

parseXMLbaik-baik saja, parseXmljugacamelCase

XMLHTTPRequestharus XmlHttpRequestatau xmlHttpRequesttidak ada cara untuk pergi dengan akronim huruf besar berikutnya, itu pasti tidak jelas untuk semua kasus uji.

mis. bagaimana Anda membaca kata ini HTTPSSLRequest ,, ( HTTP + SSLatau HTTPS + SL(itu tidak berarti apa-apa selain ...), dalam hal ini ikuti konvensi kasus unta dan pergi untuk httpSslRequestatau httpsSlRequest, mungkin itu tidak lagi baik, tetapi jelas lebih jelas.

Ada airbnb JavaScript Style Guide di github dengan banyak bintang (~ 57.5k saat ini) dan panduan tentang akronim yang mengatakan:

Akronim dan inisialisasi harus selalu menggunakan huruf kapital semua, atau semua huruf kecil.

Mengapa? Nama adalah untuk keterbacaan, bukan untuk menenangkan algoritma komputer.

// bad
import SmsContainer from './containers/SmsContainer';

// bad
const HttpRequests = [
  // ...
];

// good
import SMSContainer from './containers/SMSContainer';

// good
const HTTPRequests = [
  // ...
];

// also good
const httpRequests = [
  // ...
];

// best
import TextMessageContainer from './containers/TextMessageContainer';

// best
const requests = [
  // ...
];

Saat ini saya menggunakan aturan berikut:

1. Kasus modal untuk akronim: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

2. Camelcase untuk singkatan: ID[entifier], Exe[cutable], App[lication].

ID adalah pengecualian, maaf tapi benar.

Ketika saya melihat huruf kapital saya menganggap akronim, yaitu kata yang terpisah untuk setiap huruf. Singkatan tidak memiliki kata-kata yang terpisah untuk setiap huruf, jadi saya menggunakan kasing unta.

XMLHTTPRequest ambigous, tetapi ini adalah kasus yang jarang dan tidak terlalu ambigu, jadi tidak apa-apa, aturan dan logika lebih penting daripada keindahan.

Panduan gaya JavaScript Airbnb berbicara sedikit tentang ini . Pada dasarnya:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Karena saya biasanya membaca huruf kapital sebagai kelas, saya cenderung menghindarinya. Pada akhirnya, itu semua adalah preferensi.

Selain apa yang dikatakan @valex, saya ingin merangkum beberapa hal dengan jawaban yang diberikan untuk pertanyaan ini.

Saya pikir jawabannya adalah: itu tergantung pada bahasa pemrograman yang Anda gunakan.

C tajam

Microsoft telah menulis beberapa pedoman di mana tampaknya itu HtmlButtonadalah cara yang tepat untuk memberi nama kelas untuk kasus ini.

Javascript

Javascript memiliki beberapa variabel global dengan akronim dan menggunakan semuanya dalam huruf besar (tapi lucu, tidak selalu konsisten) di sini adalah beberapa contoh:

encodeURIComponent XMLHttpRequest toJSON toISOString

disclaimer: Bahasa Inggris bukan nada ibu saya. Tapi saya sudah memikirkan masalah ini untuk waktu yang lama, terutama ketika menggunakan node (gaya camelcase) untuk menangani database karena nama bidang tabel harus di-snake, ini adalah pemikiran saya:

Ada 2 jenis 'akronim' untuk seorang programmer:

• dalam bahasa alami, UNESCO
• dalam bahasa pemrograman komputer, misalnya tmc and textMessageContainer, yang biasanya muncul sebagai variabel lokal.

Dalam dunia pemrograman, semua akronim dalam bahasa alami harus diperlakukan sebagai kata , alasannya adalah:

1. ketika kita memprogram, kita harus memberi nama variabel baik dalam gaya akronim atau non-akronim. Jadi, jika kita menamai fungsi getUNESCOProperties, itu berarti UNESCO adalah akronim (jika tidak seharusnya tidak semua huruf besar), tetapi jelas, getdan propertiesbukan akronim. jadi, kita harus memberi nama fungsi ini baik gunescop atau getUnitedNationsEdukasiScientificDanCulturalOrganizationProperties , keduanya tidak dapat diterima.

2. bahasa alami terus berkembang, dan akronim hari ini akan menjadi kata-kata besok , tetapi program harus independen dari tren ini dan bertahan selamanya.

Omong-omong, dalam jawaban yang paling banyak dipilih, IO adalah akronim dalam arti bahasa komputer (singkatan dari InputOutput), tapi saya tidak suka namanya, karena saya pikir akronim (dalam bahasa komputer) hanya boleh digunakan untuk memberi nama variabel lokal tetapi kelas / fungsi tingkat atas, sehingga InputOutput harus digunakan sebagai pengganti IO

UNESCO adalah kasus khusus karena biasanya (dalam bahasa Inggris) dibaca sebagai kata dan bukan akronim - seperti UEFA, RADA, BAFTA dan tidak seperti BBC, HTML, SSL

Ada juga konvensi camelcase lain yang mencoba mendukung keterbacaan untuk akronim dengan menggunakan huruf besar ( HTML), atau huruf kecil ( html), tetapi menghindari keduanya ( Html).

Jadi, dalam kasus Anda, Anda bisa menulis getUNESCOProperties. Anda juga bisa menulis unescoPropertiesuntuk variabel, atauUNESCOProperties untuk kelas (konvensi untuk kelas adalah mulai dengan huruf besar).

Aturan ini menjadi rumit jika Anda ingin mengumpulkan dua akronim, misalnya untuk kelas bernama Permintaan HTTP XML. Ini akan dimulai dengan huruf besar, tetapi karena XMLHTTPRequesttidak akan mudah dibaca (apakah itu Permintaan TTP XMLH?), Dan XMLhttpRequestakan melanggar konvensi camelcase (apakah itu Permintaan XM Lhttp?), Pilihan terbaik adalah dengan menggabungkan case:, XMLHttpRequestyang merupakan sebenarnya apa yang digunakan W3C . Namun menggunakan penamaan semacam ini tidak disarankan. Untuk contoh ini, HTTPRequestakan menjadi nama yang lebih baik.

Karena kata bahasa Inggris resmi untuk identifikasi / identitas tampaknya adalah ID, meskipun bukan akronim, Anda dapat menerapkan aturan yang sama di sana.

Konvensi ini tampaknya cukup populer di luar sana, tetapi itu hanya sebuah konvensi dan tidak ada yang benar atau salah. Cobalah untuk tetap berpegang pada konvensi dan pastikan nama Anda dapat dibaca.