Akronim dalam CamelCase [ditutup]


243

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


2
Bukankah ini harus di programer.SE?
Pacerier

5
Konversi IMO ke snake_case mengungkapkan solusi terbaik. Apakah Anda suka get_unesco_propertiesatau tidak get_u_n_e_s_c_o_properties?
jchook


Jawaban:


195

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.


11
Saya kira saya harus mulai menggunakan IDsebagai gantinya Id(yang saya gunakan / lihat di mana-mana)
jasoncript

30
Secara teknis "ID" bukan akronim (ini adalah singkatan dari "pengenal" atau "identifikasi"), tapi saya tidak benar-benar tahu bagaimana / jika panduan ini membantu dengan yang itu. : - \
bryant

64
Saya rasa ini bukan standar yang baik. Membedakan akronim normal, akronim dua huruf, dan kata-kata normal tampaknya terlalu rumit dan bertentangan dengan gagasan memiliki konvensi penamaan yang konsisten.
Sam

40
Juga, dinyatakan oleh Microsoft tidak membuat sesuatu yang "benar".
Sam

48
Sangat menyenangkan mengetahui mereka mengikuti pedoman mereka sendiri: XMLHttpRequest()aslinya berasal dari Microsoft.
Makyen

315

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 TaxesusTaxes
  • Player IDplayerId

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

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

26
1) Tidak ada ketidakkonsistenan. "Id" adalah singkatan , bukan akronim. 2) Itu tergantung pada konteks pengidentifikasi, yaitu, kelas, antarmuka, atribut, tipe enumerasi, bidang statis, parameter, metode, properti atau peristiwa. Jika pedoman untuk pengidentifikasi menggunakan PascalCase, maka itu akan menjadi USTaxesdan PlayerId; camelCase: usTaxesdan playerId. 3) Itu akan USIddi PascalCase, usIddi camelCase , dan parseDbmXmldi camelCase.
Frederik Krautwald

6
Anda benar, ini singkatan. Maksud saya adalah seharusnya UsTax, UsID. "Singkatan atau akronim" dua huruf tidak boleh diperlakukan secara berbeda dari tiga huruf, atau "kata-kata normal" lainnya. Saran lain, dari jawaban @ Eonil, adalah untuk menghindari pemendek sama sekali. unitedStatesTaxes, atau playerIdentifier.
Kacang Merah

3
Ha ha. Saya ragu kebingungan akan muncul - banyak - tetapi pedoman, yah, pedoman untuk mencegah kemungkinan kebingungan. Contoh akronim yang dibuat-buat (buruk) dalam konteks sains: InIN(item)vs InIn(item)(petunjuk: IN adalah inci). Atau, IDById(id)vs IdById(id), ilmu konteks (petunjuk: ID berarti penyakit menular). "Panjang dua karakter" - apa dalam konteks apa?
Frederik Krautwald

2
Di tautan Microsoft "... gunakan case Pascal atau case unta untuk akronim yang panjangnya lebih dari dua karakter . ... Namun, Anda harus menggunakan huruf besar akronim yang hanya terdiri dari dua karakter ..." Itulah bagian yang saya sebut "tidak konsisten ". Karakterisasi yang lebih baik adalah "pengecualian". Dan setidaknya Anda telah merasionalisasi mengapa dua akronim huruf mungkin lebih membingungkan. Tapi saya kira program-program dengan "CanCan" itu kurang beruntung; ambigu apakah itu gerakan tarian, atau Jaringan Area Komunitas Cercle de l'Aviron de Nantes :)
The Red Pea

18
Penulis Capital Offense: Cara Menangani Singkatan di CamelCase dengan benar memanggil istilah "kekejian" ketika ia menulis: "Sementara [menggunakan akronim huruf besar] bekerja dalam kasus-kasus sederhana, itu mengarah pada kekejian ketika satu singkatan mengikuti yang lain: HTTPURLConnection, XMLIDREF"
kghastie

21

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 .


4
Contoh-contoh di atas agak menyesatkan. "Pendekatan terbaik yang pernah saya lihat adalah Apple ... Itu berarti memperlakukan akronim seperti kata benda yang tepat ... Jadi UNESCO lebih masuk akal" - Bukan itu cara Anda menulis kata benda yang tepat.
Mikko Rantanen

@MikkoRantanen Saya memperbarui jawaban saya.
Eonil

7
Wow saya hampir tidak dapat menemukan kalimat dalam jawaban yang saya setuju dengan :-)
Josef Sábl

Ini sepenuhnya tergantung pada konteks kode yang Anda kerjakan apakah singkatan / akronim lebih masuk akal atau tidak. Misalnya, saya bekerja di bidang keuangan, dan ada begitu banyak istilah unik yang seragam di seluruh industri dan bahkan di seluruh dunia. Anda akan membuang-buang waktu dan menciptakan kata-kata yang tidak perlu dengan tidak menggunakan akronim yang semua orang akan bekerja di perusahaan itu hafal. Misalnya PV untuk nilai sekarang, FV untuk nilai masa depan, rata-rata untuk rata-rata, exp untuk eksponen, dll.
Will Ediger

@ pm100 Bukankah itu yang saya katakan? UNESCO bukan bagaimana Anda menulis kata benda yang tepat.
Mikko Rantanen

17

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.


17

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.


2
Saya suka HTTPSSLcontoh Anda , meskipun SL tidak berarti apa-apa, bagaimana dengan sesuatu seperti HTTPSSHTunnel? Apakah itu HTTPS + SH (shell) atau HTTP + SSH? Konvensi Google jelas kurang ambigu.
L. Holanda

10

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 = [
  // ...
];

7
" Kenapa? Nama adalah untuk keterbacaan, bukan untuk menenangkan algoritma komputer " jadi, XMLHTTPRequestapakah cara ini lebih baik dibaca daripada XmlHttpRequest, kan?
L. Holanda

2
Tidak masuk akal mengapa httpRequestsdianggap baik tetapi HttpRequestsburuk. mengikuti prinsip ini maka, untuk Permintaan HTTP XML harus xmlhttpRequest???
L. Holanda

1
Saya sering mengutip panduan gaya AirBnb, tetapi dalam hal ini saya tidak setuju. Saya khususnya tidak setuju dengan pernyataan mereka: "Akronim dan inisialisasi harus selalu semua huruf besar, atau semua huruf kecil." xmlHttpRequestlebih mudah dibaca daripada XMLHTTPRequestmenurut saya.
Ronan

3

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.


1

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.


1

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


Yah itu Netscape lama, bahkan memiliki beberapa tanpa camelCase seperti onerror.
Eddie

1

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


"lidah", bukan "nada"
Dan Dascalescu

0

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


1
Inilah perbedaan antara "akronim" dan "singkatan" belaka; perbedaan ini tampaknya relevan dengan seluruh diskusi, tetapi hampir seluruhnya telah dielakkan dalam jawaban yang disajikan.
simon

BBC, HTML, SSL, dan akronim lain tempat Anda membacakan setiap huruf lebih akurat disebut inisialisasi. Kata-kata seperti UNESCO yang diucapkan sebagai kata adalah akronim yang benar.
Lrdwhyt

-2

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.


3
Saya tidak percaya seluruh utas ini :-) Jadi itu XMLToHtmlConverter tapi HTMLToXmlConverter? Wow ...
Josef Sábl

1
@ JosefSábl, ya, akan seperti itu. Mengenai downvote Anda, saya tidak mengatakan saya suka konvensi ini, tetapi pasti ada.
Jesús Carrera

1
Saya membaca pertanyaan sebagai "Apa konvensi yang baik untuk menulis Akronim dalam huruf unta" bukan "Bisakah Anda mendaftar semua konvensi yang ada". Dan karena saya menganggap konvensi yang Anda sebutkan itu sangat buruk, saya menurunkan suara :-)
Josef Sábl

Nah pertanyaannya adalah "Apakah benar menulis dengan cara ini?", Dan karena ada banyak cara "benar" untuk menulisnya karena itu hanya sebuah konvensi, dan konvensi ini cukup populer (terlepas dari bagaimana Anda menganggapnya), saya jawabannya sangat valid :-)
Jesús Carrera
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.