Някои насоки, които Microsoft е написал за camelCase са:

Когато използвате акроними, използвайте малки и големи букви Pascal или camel за съкращения с дължина повече от два знака. Например използвайте HtmlButton или htmlButton. Трябва обаче да изписвате с главни букви акроними, които се състоят само от два знака, като например System.IO вместо System.Io.

Не използвайте съкращения в идентификатори или имена на параметри. Ако трябва да използвате съкращения, използвайте камилски главни букви за съкращения, които се състоят от повече от два знака, дори ако това противоречи на стандартното съкращение на думата.

Обобщаване:

• Когато използвате съкращение или акроним с дължина два знака, пишете всички с главни букви;

• Когато акронимът е по-дълъг от два знака, използвайте главна буква за първия знак.

Така че във вашия конкретен случай getUnescoProperties() е правилно.

Има основателни критики към съветите на Microsoft от приетия отговор.

• Inconsistent treatment of acronyms/initialisms depending on number of characters:
  • playerID vs playerId vs playerIdentifier.
• The question of whether two-letter acronyms should still be capitalized if they appear at the start of the identifier:
  • USTaxes vs usTaxes
• Difficulty in distinguishing multiple acronyms:
  • i.e. USID vs usId (or parseDBMXML in Wikipedia's example).

Така че ще публикувам този отговор като алтернатива на приетия отговор. Всички акроними трябва да се третират последователно; акронимите трябва да се третират като всяка друга дума. Цитиране на Уикипедия:

...някои програмисти предпочитат да третират съкращенията като думи с малки букви...

Така че отново: въпросът на OP, съгласен съм с приетия отговор; това е правилно: getUnescoProperties()

Но мисля, че ще стигна до различно заключение в тези примери:

• US Taxes → usTaxes
• Player ID → playerId

Така че гласувайте за този отговор, ако смятате, че двубуквените акроними трябва да се третират като другите акроними.

Camel Case е конвенция, а не спецификация. Така че предполагам правилата на популярното мнение.

( РЕДАКТИРАНЕ: Премахване на това предложение, че гласовете трябва да решават този въпрос; както казва @Brian David; Stack Overflow не е „състезание за популярност“ и този въпрос беше затворен като „базиран на мнение“)

Въпреки че мнозина предпочитат да третират акронимите като всяка друга дума, по-често срещаната практика може да е да се поставят акроними с главни букви (въпреки че това води до „мерзости“)

• Вижте „EDXML“ в тази XML схема
• Вижте "SFAS158" в тази XBRL схема

Други ресурси:

• Имайте предвид, че някои хора правят разлика между съкращение и акроними
• Забележка Указанията на Microsoft правят разлика между акроними с два знака и „акроними с повече от два знака“
• Обърнете внимание, че някои хора препоръчват да се избягват напълно съкращенията/акронимите
• Имайте предвид, че някои хора препоръчват да избягвате напълно CamelCase / PascalCase
• Обърнете внимание, че някои хора правят разлика между „последователност“ като „правила, които изглеждат вътрешно непоследователни“ (т.е. третиране на акроними с два знака по различен начин от акроними с три знака); някои хора определят „последователност“ като „последователно прилагане на едно и също правило“ (дори ако правилото е вътрешно непоследователно)
• Указания за проектиране на рамка
• Указания на Microsoft

За преобразуване в CamelCase има и (почти) детерминистичен Camel case на Google алгоритъм:

Започвайки с прозаичната форма на името:

1. Преобразувайте фразата в обикновен ASCII и премахнете всички апострофи. Например „алгоритъм на Мюлер“ може да стане „алгоритъм на Мюлер“.
2. Divide this result into words, splitting on spaces and any remaining punctuation (typically hyphens).
   1. Recommended: if any word already has a conventional camel case appearance in common usage, split this into its constituent parts (e.g., "AdWords" becomes "ad words"). Note that a word such as "iOS" is not really in camel case per se; it defies any convention, so this recommendation does not apply.
3. Now lowercase everything (including acronyms), then uppercase only the first character of:
   1. … each word, to yield upper camel case, or
   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, може би вече не е хубаво, но определено е по-ясно.

Има airbnb JavaScript Style Guide в github с много звезди (~57,5k към този момент) и ръководства относно акроними, които казват:

Акронимите и инициализите трябва винаги да са с главни букви или с малки букви.

Защо? Имената са за четливост, а не за успокояване на компютърен алгоритъм.

// 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 case за съкращения: ID[entifier], Exe[cutable], App[lication].

ID е изключение, съжалявам, но е така.

Когато видя главна буква, приемам акроним, т.е. отделна дума за всяка буква. Съкращенията нямат отделни думи за всяка буква, затова използвам камилски регистър.

XMLHTTPRequest е двусмислено, но това е рядък случай и не е толкова двусмислено, така че е добре, правилата и логиката са по-важни от красотата.

В допълнение към казаното от @valex, искам да повторя няколко неща с дадените отговори на този въпрос.

Мисля, че общият отговор е: зависи от езика за програмиране, който използвате.

C Sharp

Microsoft написа някои насоки, където изглежда, че HtmlButton е правилният начин за наименуване на клас за тези случаи.

Javascript

Javascript има някои глобални променливи с акроними и ги използва с главни букви (но забавно, не винаги последователно) ето няколко примера:

encodeURIComponent XMLHttpRequest toJSON toISOString

Ръководството за стил на JavaScript Airbnb говори малко за това. По принцип:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Тъй като обикновено чета водеща главна буква като клас, съм склонен да избягвам това. В края на деня всичко е предпочитание.

отказ от отговорност: английският не е моят майчин тон. Но аз съм мислил за този проблем от дълго време, особено когато използвам възел (стил Camelcase) за обработка на база данни, тъй като името на полетата на таблицата трябва да бъде змийско, това е моята мисъл:

Има 2 вида „акроними“ за програмист:

• на естествен език, ЮНЕСКО
• в езика за компютърно програмиране, например tmc and textMessageContainer, който обикновено се появява като локална променлива.

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

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

2. естественият език се развива непрекъснато и днешните акроними ще станат думи утре, но програмите трябва да са независими от тази тенденция и да стоят вечно.

между другото, в отговора с най-много гласове IO е акронимът на компютърен език, който означава (съкращение от InputOutput), но не ми харесва името, тъй като смятам, че съкращението (на компютърен език) трябва да се използва само за име локална променлива, но клас/функция от най-високо ниво, така че InputOutput трябва да се използва вместо IO

ЮНЕСКО е специален случай, тъй като обикновено (на английски) се чете като дума, а не като акроним - като UEFA, RADA, BAFTA и за разлика от BBC, HTML, SSL

Има и друга конвенция за камилски букви, която се опитва да благоприятства четливостта на акронимите, като използва главни (HTML) или малки букви (html), но избягва и двете (Html).

Така че във вашия случай можете да напишете getUNESCOProperties. Можете също така да напишете unescoProperties за променлива или UNESCOProperties за клас (конвенцията за класовете е да започват с главни букви).

Това правило става трудно, ако искате да съберете два акронима, например за клас, наречен XML HTTP заявка. Ще започне с главни букви, но тъй като XMLHTTPRequest няма да е лесен за четене (дали е XMLH TTP заявка?), а XMLhttpRequest ще наруши конвенцията за Camelcase (дали е XM Lhttp заявка?), най-добрият вариант би бил смесването на малки и големи букви: XMLHttpRequest , което всъщност е това, което W3C използва. Използването на този вид имена обаче не се препоръчва. За този пример HTTPRequest би било по-добро име.

Тъй като официалната английска дума за идентификация/идентификация изглежда е ID, въпреки че не е акроним, можете да приложите същите правила там.

Тази конвенция изглежда доста популярна там, но това е просто конвенция и няма правилно или грешно. Просто се опитайте да се придържате към конвенция и се уверете, че имената ви са четливи.