У меня есть сомнения по поводу CamelCase. Предположим, у вас есть эта аббревиатура:Unesco = United Nations Educational, Scientific and Cultural Organization.

Вы должны написать: unitedNationsEducationalScientificAndCulturalOrganization

Но что, если вам нужно написать акроним? Что-то вроде:

getUnescoProperties();

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

Вот некоторые рекомендации, которые Microsoft написала camelCase:

При использовании аббревиатур используйте регистр Pascal или верблюд для аббревиатур длиной более двух символов. Например, используйте HtmlButtonили htmlButton. Тем не менее, вы должны использовать заглавные буквы, которые состоят только из двух символов, например System.IOвместо System.Io.

Не используйте сокращения в идентификаторах или именах параметров. Если вы должны использовать сокращения, используйте верблюжий регистр для сокращений, которые состоят из более чем двух символов, даже если это противоречит стандартной аббревиатуре слова.

Подводя итог:

• Когда вы используете аббревиатуру или аббревиатуру длиной два символа, поместите их все в прописные буквы;

• Если аббревиатура длиннее двух символов, используйте заглавную букву для первого символа.

Так что, в вашем конкретном случае getUnescoProperties()это правильно.

Есть обоснованная критика совета Microsoft из принятого ответа.

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

Поэтому я опубликую этот ответ как альтернативу принятому ответу. Все аббревиатуры должны рассматриваться последовательно; аббревиатуры следует трактовать как любое другое слово. Цитируя Википедию :

... некоторые программисты предпочитают обрабатывать сокращения, как если бы они были строчными словами ...

Итак, вопрос OP: я согласен с принятым ответом; это верно:getUnescoProperties()

Но я думаю, что я бы пришел к другому выводу в этих примерах:

• US Taxes → usTaxes
• Player ID → playerId

Поэтому проголосуйте за этот ответ, если считаете, что двухбуквенные аббревиатуры следует рассматривать как другие аббревиатуры.,

Случай с верблюдом - это соглашение, а не спецификация. Так что я думаю, что популярные правила мнения.

( РЕДАКТИРОВАТЬ: удаление этого предложения о том, что голосование должно решить эту проблему; как говорит @Brian David; Stack Overflow не является «конкурсом популярности», и этот вопрос был закрыт как «основанный на мнении»)

Несмотря на то, что многие предпочитают относиться к аббревиатурам как к любому другому слову, более распространенная практика может заключаться в том, чтобы ставить аббревиатуры в заглавные буквы (даже если это приводит к «мерзостям»).

• Смотрите "EDXML" в этой схеме XML
• Смотрите "SFAS158" в этой схеме XBRL

Другие источники:

• Обратите внимание, что некоторые люди различают аббревиатуру и аббревиатуру
• Примечание. В рекомендациях Microsoft проводится различие между двухбуквенными аббревиатурами и «аббревиатурами длиной более двух символов».
• Обратите внимание, что некоторые люди рекомендуют избегать сокращений / аббревиатур вообще
• Обратите внимание, что некоторые люди рекомендуют вообще избегать использования CamelCase / PascalCase
• Обратите внимание, что некоторые люди различают «согласованность» как «правила, которые кажутся внутренне непоследовательными» (т. Е. Трактуют аббревиатуры из двух символов, отличные от аббревиатур из трех символов); некоторые люди определяют «последовательность» как «последовательно применяя одно и то же правило» (даже если правило внутренне несовместимо)
• Руководство по проектированию рамок
• Руководство Microsoft

Во-первых, я должен уточнить, что я не являюсь носителем английского языка , поэтому мое утверждение о грамматике английского языка может быть просто неверным. Если вы обнаружите такие ошибки, пожалуйста, дайте мне знать, и я буду очень благодарен.

Лучшая практика для аббревиатуры будет избегать сокращений в максимально возможной степени. Во всяком случае, это не так, потому что аббревиатура UNESCOболее знакома, чем полное имя UnitedNationsEducationalScientificAndCulturalOrganization.

Тогда, я думаю, что это UNESCOимеет больше смысла, чем Unescoпросто потому, что это ближе к реальной жизни, поэтому более знакомо. У меня были некоторые проблемы, чтобы понять, что на Unescoсамом деле означает это слово .

В качестве другого примера подумайте Arc. Это звучит как кривая вокруг круга, но в Rust это означает Atomically Reference Counted. Если бы оно было написано так ARC, по крайней мере, читатели признали бы, что слово является аббревиатурой от чего-то другого, а не от кривой.

Современные программы написаны в основном для читателей. Затем эти правила именования должны быть установлены для удобства чтения человеком, а не для машинной обработки или анализа.

С этой точки зрения мы теряем читабельность, используя Unescoover, UNESCOно ничего не получая.

И для любых других случаев, я думаю, что простого соблюдения простых правил (или соглашений) аббревиатуры на английском языке достаточно для большинства случаев для лучшей читабельности .

Чтобы преобразовать в CamelCase, есть также (почти) детерминистический алгоритм случая с верблюдом от Google :

Начиная с прозаической формы имени:

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

Обратите внимание, что регистр исходных слов почти полностью игнорируется.

В следующих примерах «XML-HTTP-запрос» правильно преобразуется в XmlHttpRequest, XMLHTTPRequest неверен.

getUnescoProperties() должно быть лучшим решением ...

Когда это возможно, просто следуйте чистому camelCase, когда у вас есть аббревиатуры, просто по возможности пишите их в верхнем регистре, иначеcamelCase .

Обычно в программировании ОО переменные должны начинаться с буквы нижнего регистра ( lowerCamelCase), а класс должен начинаться с буквы верхнего регистра (UpperCamelCase ).

Когда сомневаешься, просто становись чистым camelCase;)

parseXMLхорошо, parseXmlтакжеcamelCase

XMLHTTPRequestДолжен быть XmlHttpRequestили xmlHttpRequestнет способ идти с последующими прописными аббревиатурами, это окончательно не ясно для всех тестовых случаев.

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

На github есть airbnb JavaScript Style Guide с большим количеством звездочек (~ 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, я хочу напомнить пару вещей с данными ответами на этот вопрос.

Я думаю, что общий ответ: это зависит от языка программирования, который вы используете.

С Sharp

Microsoft написала несколько руководящих принципов, в которых кажется, что HtmlButtonэто правильный способ назвать класс для этих случаев.

Javascript

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

encodeURIComponent XMLHttpRequest toJSON toISOString

Отказ от ответственности: английский не мой родной тон. Но я долго думал об этой проблеме, особенно при использовании узла (стиль camelcase) для обработки базы данных, так как имя полей таблицы должно быть змеино, это моя мысль:

Для программиста есть два вида аббревиатур:

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

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

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

2. естественный язык постоянно развивается, и сегодняшние аббревиатуры станут словами завтра , но программы должны быть независимы от этой тенденции и стоять вечно.

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

ЮНЕСКО является особым случаем, так как обычно (на английском языке) читается как слово, а не как аббревиатура - как УЕФА, РАДА, БАФТА и в отличие от BBC, HTML, SSL

Существует также другое соглашение о верблюдах, которое пытается улучшить удобочитаемость для акронимов, используя uppercase ( HTML) или lowercase ( html), но избегая обоих ( Html).

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

Это правило становится сложным, если вы хотите соединить две аббревиатуры, например, для класса с именем XML HTTP Request. Это будет начинаться с заглавной буквы, но так какXMLHTTPRequest его будет нелегко прочитать (это XMLH TTP Request?) И XMLhttpRequestнарушит соглашение о верблюдах (XM Lhttp Request?), Лучшим вариантом будет смешать case:, XMLHttpRequestкоторый на самом деле то, что использовал W3C . Однако использование такого рода наименований не рекомендуется. Для этого примера HTTPRequestбудет лучше имя.

Поскольку официальное английское слово для идентификации / идентификации, кажется, ID, хотя это не аббревиатура, вы можете применить там те же правила.

Это соглашение кажется довольно популярным, но это просто соглашение, в котором нет правильного или неправильного. Просто попробуйте придерживаться соглашения и убедитесь, что ваши имена читабельны.