У мене є сумніви щодо CamelCase. Припустимо, у вас є ця абревіатура:Unesco = United Nations Educational, Scientific and Cultural Organization.

Ви повинні написати: unitedNationsEducationalScientificAndCulturalOrganization

Але що робити, якщо вам потрібно написати абревіатуру? Щось на зразок:

getUnescoProperties();

Чи правильно це писати так? getUnescoProperties() OR getUNESCOProperties();

Деякі вказівки , про camelCaseякі написала Microsoft :

Використовуючи абревіатури, використовуйте регістр Паскаль або регістр верблюда для акронімів довжиною більше двох символів. Наприклад, використовувати HtmlButtonабо htmlButton. Однак слід використовувати великі літери, що складаються лише з двох символів, наприклад System.IOзамість System.Io.

Не використовуйте абревіатури в ідентифікаторах або назвах параметрів. Якщо вам потрібно використовувати абревіатури, використовуйте корпус верблюда для скорочень, які складаються з двох символів, навіть якщо це суперечить стандартній абревіатурі слова.

Підводячи підсумки:

• Якщо ви використовуєте абревіатуру або абревіатуру, яка має два символи, покладіть їх у великі літери;

• Коли абревіатура довша двох символів, використовуйте велику літер для першого символу.

Отже, у вашому конкретному випадку getUnescoProperties()це правильно.

У зв'язку із прийнятою відповіддю є справедливі зауваження щодо порад Microsoft .

• Непослідовне трактування абревіатур / ініціалізмів залежно від кількості символів:
  • playerIDпроти playerIdпроти playerIdentifier.
• Питання про те, чи варто все-таки використовувати великі літери, якщо вони з’являються на початку ідентифікатора:
  • USTaxes проти usTaxes
• Складність у розрізненні декількох абревіатур:
  • тобто USIDvs usId(або parseDBMXMLна прикладі Вікіпедії).

Тому я опублікую цю відповідь як альтернативу прийнятій відповіді. Усі абревіатури слід обробляти послідовно; абревіатури слід трактувати як будь-яке інше слово. Цитуючи Вікіпедію :

... деякі програмісти вважають за краще абревіатури трактувати так, ніби вони є малими словами ...

Тому повторно: питання ОП, я згоден з прийнятою відповіддю; це вірно:getUnescoProperties()

Але я думаю, я б дійшов до іншого висновку в цих прикладах:

• US Taxes → usTaxes
• Player ID → playerId

Тож голосуйте за цю відповідь, якщо ви вважаєте, що двобуквові абревіатури повинні трактуватися як інші абревіатури.

Справа верблюда - це умова, а не специфікація. Тож я здогадуюсь правил поширеної думки.

( EDIT: Видалення цієї пропозиції, щоб голоси вирішили це питання; як говорить @Brian David; Переповнення стека - це не "конкурс популярності", і це питання було закрито як "на основі думки")

Незважаючи на те, що багато хто вважає за краще ставитися до абревіатур як до будь-якого іншого слова, більш поширеною практикою може бути ставлення абревіатур у "all-caps" (хоча це призводить до "гидоти")

• Дивіться "EDXML" в цій XML-схемі
• Дивіться "SFAS158" у цій схемі XBRL

Інші ресурси:

• Зауважимо, деякі люди розрізняють абревіатуру та абревіатуру
• Зауважте, що в інструкціях Microsoft розрізняють дво символьні абревіатури та "абревіатури довше двох символів"
• Зауважте, деякі люди рекомендують взагалі уникати скорочень / абревіатур
• Зауважте, деякі люди рекомендують взагалі уникати CamelCase / PascalCase
• Зауважимо, що деякі люди розрізняють "послідовність" як "правила, які здаються внутрішньо непослідовними" (тобто трактування дво символьних абревіатур, відмінних від три символьних абревіатур); деякі люди визначають "послідовність" як "послідовно застосовувати одне і те ж правило" (навіть якщо правило є внутрішньо непослідовним)
• Рамкові рекомендації щодо дизайну
• Правила Microsoft

По-перше, я повинен уточнити, що я не є носієм англійської мови , тому моє твердження про англійську граматику може бути просто помилковим. Якщо ви виявите такі помилки, будь ласка, повідомте мене, і я буду вам дуже вдячний.

Найкращою практикою для абревіатури було б максимально уникати акронімів. Так чи інакше, це не так, оскільки абревіатура UNESCOбільше знайома, ніж повна назва UnitedNationsEducationalScientificAndCulturalOrganization.

Тоді, я думаю, це UNESCOмає більше сенсу, ніж Unescoтому, що просто це ближче до форми реального життя, настільки звичної. У мене були проблеми, щоб зрозуміти, що це слово Unescoнасправді означає.

Як інший приклад, подумайте Arc. Це звучить як крива навколо кола, але в Іржі це означає Atomically Reference Counted. Якби це було написано так ARC, принаймні читачі визнали б, що це слово є абревіатурою чогось іншого, а не якоюсь кривою.

Сучасні програми написані переважно для людських читачів. Тоді повинні бути встановлені правила іменування для читабельності людини, а не для машинної обробки чи аналізу.

З цієї точки зору, ми втрачаємо деяку легкість для читання, використовуючи Unescoбільш , UNESCOпоки не отримує нічого.

І для будь-яких інших випадків, я вважаю, що просто дотримання простих правил англійської абревіатури (або конвенцій) достатньо для більшості випадків для найкращої читабельності .

Для перетворення в CamelCase існує також (майже) детермінований алгоритм випадку Camel :

Починаючи з прозової форми назви:

1. Перетворіть фразу в звичайний ASCII і видаліть усі апострофи. Наприклад, "алгоритм Мюллера" може стати "алгоритмом Мюллера".
2. Розподіліть цей результат на слова, розділяючи пробіли та будь-які інші розділові знаки (зазвичай дефіси).
   1. Рекомендовано: якщо будь-яке слово вже має звичайний вигляд верблюда в загальному вигляді, розділіть його на складові частини (наприклад, "AdWords" стає "рекламними словами"). Зауважте, що таке слово, як "iOS", насправді не є справді у справі верблюда; він не відповідає будь-якій умові, тому ця рекомендація не застосовується.
3. Тепер усе пропишене (в тому числі і абревіатури), а тоді лише перший символ:
   1. … Кожне слово, щоб отримати верхній корпус верблюда, або
   2. … Кожне слово, окрім першого, дає нижню справу верблюда
4. Нарешті, об’єднайте всі слова в єдиний ідентифікатор.

Зауважимо, що з написання оригінальних слів майже повністю не враховується.

У наступних прикладах "XML HTTP-запит" правильно перетворений на XmlHttpRequest, XMLHTTPRequest неправильний.

getUnescoProperties() має бути найкращим рішенням ...

Коли це можливо, просто дотримуйтесь чистого camelCase, якщо у вас є абревіатури, просто відпустіть їх у верхньому регістрі, коли можливо, інакше camelCase.

Зазвичай в програмуванні OO змінні повинні починатися з малої літери ( lowerCamelCase), а клас повинен починатися з великої літери ( UpperCamelCase).

Коли сумніваєтесь, просто очистіть camelCase;)

parseXMLдобре, parseXmlтежcamelCase

XMLHTTPRequestмає бути XmlHttpRequestабо xmlHttpRequestвзагалі не підходити до наступних абревіатур верхнього регістру, остаточно не зрозуміло для всіх тестових випадків.

наприклад, як ви читаєте це слово HTTPSSLRequest, HTTP + SSLабо HTTPS + SL(це не означає нічого, окрім…), у такому випадку дотримуйтесь конвенції справи про верблюдів та йдіть на, httpSslRequestабо httpsSlRequest, можливо, це вже не приємно, але це, безумовно, більш зрозуміло.

У github є airbnb Guide для стилю JavaScript з великою кількістю зірок (~ 57,5 ​​тис. На даний момент) та посібники про абревіатури, які говорять:

Акроніми та ініціалізми завжди мають бути написані з великої літери або всі з малої літери.

Чому? Назви призначені для читабельності, а не для заспокоєння комп'ютерного алгоритму.

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

В даний час я використовую такі правила:

1. Капітал випадку абревіатур: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

2. Camel разі скорочень: ID[entifier], Exe[cutable], App[lication].

ID виняток, вибачте, але правда.

Коли я бачу велику літеру, я припускаю абревіатуру, тобто окреме слово для кожної літери. У скороченнях немає окремих слів для кожної літери, тому я використовую випадок верблюда.

XMLHTTPRequest є неоднозначним, але це рідкісний випадок, і це не так багатозначно, тому це нормально, правила і логіка важливіші, ніж краса.

Посібник зі стилю JavaScript Airbnb трохи розповідає про це . В основному:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Оскільки я зазвичай читаю провідну велику літеру як клас, я схиляюсь цього уникати. Зрештою, все вподобано.

Окрім того, що сказав @valex, я хочу скласти ще кілька речей із поданими відповідями на це питання.

Я думаю, що загальна відповідь така: це залежить від мови програмування, яку ви використовуєте.

C Різкий

Microsoft написала деякі вказівки, де здається, що HtmlButtonце правильний спосіб назвати клас для цих випадків.

Javascript

У Javascript є кілька глобальних змінних з абревіатурами, і він використовує їх у верхньому регістрі (але смішно, не завжди послідовно) ось кілька прикладів:

encodeURIComponent XMLHttpRequest toJSON toISOString

відмова від відповідальності: Англійська мова не є моїм материнським тоном. Але я довго думав над цією проблемою, особливо при використанні вузла (стиль верблюда) для обробки бази даних, оскільки ім’я полів таблиці слід зміяти, це моя думка:

Існує 2 види "абревіатур" для програміста:

• природною мовою, ЮНЕСКО
• наприклад, в мові програмування комп'ютера tmc and textMessageContainer, яка зазвичай представляється локальною змінною.

У світі програмування всі абревіатури природною мовою слід розглядати як слово , причини:

1. при програмуванні ми повинні називати змінну або в стилі абревіатури, або в стилі неакронім. Отже, якщо ми називаємо функцію getUNESCOProperties, це означає, що ЮНЕСКО є абревіатурою (інакше це не повинні бути всі великі літери), але, очевидно, getі propertiesне є абревіатурами. Таким чином, ми повинні називати цю функцію або gunescop, або getUnitedNationsEducationalScientistAndCulturalOrganizationProperties , обидва неприйнятні.

2. Природна мова постійно розвивається, і сьогоднішні акроніми стануть словами завтра , але програми повинні бути незалежними від цієї тенденції і стояти назавжди.

До речі, у найбільш голосовій відповіді IO - це абревіатура в значенні комп’ютерної мови (означає InputOutput), але це ім'я мені не подобається, оскільки я думаю, що абревіатура (на комп'ютерній мові) повинна використовуватися лише для імені локальна змінна, але клас / функція вищого рівня, тому InputOutput слід використовувати замість IO

ЮНЕСКО - особливий випадок, оскільки його зазвичай (англійською) читають як слово, а не абревіатуру - як УЄФА, RADA, BAFTA та на відміну від BBC, HTML, SSL

Існує також ще одна угода про верблюжість, яка намагається сприяти читанню для абревіатур, використовуючи або великі HTMLрегістри ( html), або малі регістри ( ), але уникаючи обох ( Html).

Тож у вашому випадку ви могли написати getUNESCOProperties. Ви також можете написати unescoPropertiesдля змінної або UNESCOPropertiesдля класу (умова для класів починається з великої літери).

Це правило стає складним, якщо ви хочете скласти дві абревіатури, наприклад для класу XML HTTP Request. XMLHTTPRequestПочнеться з великого регістру, але оскільки прочитати його буде непросто (це XMLH TTP-запит?), І XMLhttpRequestпорушив би угоду верблюда (це XM Lhttp Request?), Найкращим варіантом було б змішати регістр:, XMLHttpRequestщо є власне те, що використовував W3C . Однак використання подібних назв не рекомендується. Для цього прикладу HTTPRequestбуло б краще ім’я.

Оскільки офіційне англійське слово для ідентифікації / ідентичності, здається, є ідентифікатором, хоча це не є абревіатурою, ви можете застосувати ті самі правила там.

Ця конвенція здається досить популярною там, але це просто умова, і немає правильного чи неправильного. Просто спробуйте дотримуватися конвенції і переконайтеся, що ваші імена читаються.