Сокращения в CamelCase
У меня есть сомнения по поводу CamelCase. Предположим, у вас есть эта аббревиатура: Unesco = United Nations Educational, Scientific and Cultural Organization.
Вы должны написать: unitedNationsEducationalScientificAndCulturalOrganization
Но что, если вам нужно написать акроним? Что-то вроде:
getUnescoProperties();
Правильно ли так написать? getUnescoProperties() OR getUNESCOProperties();
12 ответов
Некоторые рекомендации, которые Microsoft написала о camelCase
являются:
При использовании аббревиатур используйте регистр Pascal или верблюд для аббревиатур длиной более двух символов. Например, используйте
HtmlButton
или жеhtmlButton
, Тем не менее, вы должны использовать заглавные буквы, которые состоят только из двух символов, таких какSystem.IO
вместоSystem.Io
,Не используйте сокращения в идентификаторах или именах параметров. Если вы должны использовать сокращения, используйте верблюжий регистр для сокращений, которые состоят более чем из двух символов, даже если это противоречит стандартной аббревиатуре слова.
Подводя итог:
Когда вы используете аббревиатуру или аббревиатуру длиной два символа, поместите их все в прописные буквы;
Если аббревиатура длиннее двух символов, используйте заглавную букву для первого символа.
Итак, в вашем конкретном случае, getUnescoProperties()
верно.
Есть обоснованная критика совета Microsoft из принятого ответа.
- Непоследовательная обработка аббревиатур / инициализмов в зависимости от количества символов:
playerID
противplayerId
противplayerIdentifier
,
- Вопрос о том, должны ли двухбуквенные аббревиатуры быть заглавными, если они появляются в начале идентификатора:
USTaxes
противusTaxes
- Сложность в различении нескольких сокращений:
- т.е.
USID
противusId
(или жеparseDBMXML
в примере Википедии).
- т.е.
Поэтому я опубликую этот ответ как альтернативу принятому ответу. Голоса могут решить. Все аббревиатуры должны рассматриваться последовательно; аббревиатуры следует трактовать как любое другое слово. Цитируя Википедию:
... некоторые программисты предпочитают обрабатывать сокращения, как если бы они были строчными словами...
Итак, я отвечаю на вопрос ОП, я согласен с принятым ответом; это правильно: getUnescoProperties()
Но я думаю, что я бы пришел к другому выводу в этих примерах:
US Taxes
→usTaxes
Player ID
→playerId
Поэтому голосуйте за этот ответ, если считаете, что двухбуквенные аббревиатуры следует рассматривать как другие аббревиатуры.
Случай с верблюдом - это соглашение, а не спецификация. Так что я думаю, что популярные правила мнения.
И при поиске "популярного" ответа в существующем коде или разметке, возможно, принятый ответ понял это правильно.
- Смотрите "EDXML" в этой схеме XML
- Смотрите "SFAS158" в этой схеме XBRL
Чтобы преобразовать в CamelCase, есть также (почти) детерминистический алгоритм случая с верблюдом от Google:
Начиная с прозаической формы имени:
- Преобразуйте фразу в обычный ASCII и удалите все апострофы. Например, "алгоритм Мюллера" может стать "алгоритмом Мюллера".
- Разделите этот результат на слова, разделяя их на пробелы и оставшиеся знаки препинания (обычно дефисы).
- Рекомендуется: если какое-либо слово уже имеет общепринятую форму обычного случая с верблюдом, разделите его на составные части (например, "AdWords" становится "рекламными словами"). Обратите внимание, что такое слово, как "iOS", на самом деле не совсем верблюжье; он не поддается никаким соглашениям, поэтому данная рекомендация не применяется.
- Теперь строчными буквами все (включая аббревиатуры), затем прописными буквами только первый символ:
- ... каждое слово, чтобы привести верхний регистр верблюда, или
- … Каждое слово, кроме первого, дает нижний регистр верблюда
- Наконец, объедините все слова в один идентификатор.
Обратите внимание, что регистр исходных слов почти полностью игнорируется.
В следующих примерах "HTTP-запрос XML" правильно преобразуется в XmlHttpRequest, XMLHTTPRequest является неправильным.
getUnescoProperties()
должно быть лучшим решением...
Когда возможно, просто следуйте чистым camelCase
, когда у вас есть сокращения, просто введите их в верхнем регистре, если это возможно, иначе camelCase
,
Обычно в программировании ОО переменные должны начинаться со строчной буквы (lowerCamelCase
) и класс должен начинаться с заглавной буквы (UpperCamelCase
).
Когда сомневаешься, просто становись чистым camelCase
;)
parseXML
Это хорошо, parseXml
это также camelCase
XMLHTTPRequest
должно быть XmlHttpRequest
или же xmlHttpRequest
нет никакого способа пойти с последующими акронимами в верхнем регистре, это определенно не ясно для всех тестовых случаев.
например, как вы читаете это слово HTTPSSLRequest
, HTTP + SSL
, или же HTTPS + SL
(это ничего не значит, но...), в этом случае следуйте соглашению о верблюде httpSslRequest
или же httpsSlRequest
Может быть, это уже не приятно, но это определенно более ясно.
Во-первых, я должен уточнить, что я не являюсь носителем английского языка, поэтому мое утверждение о грамматике английского языка может быть просто неверным. Если вы обнаружите такие ошибки, пожалуйста, дайте мне знать, и я буду очень благодарен.
Лучшая практика для аббревиатуры будет избегать сокращений в максимально возможной степени. Во всяком случае, это не так, потому что аббревиатура UNESCO
более знаком, чем полное имя UnitedNationsEducationalScientificAndCulturalOrganization
,
Тогда я думаю UNESCO
имеет больше смысла, чем Unesco
потому что просто это ближе к реальной жизни, так более знакомо. У меня были некоторые проблемы, чтобы понять, что это за слово Unesco
на самом деле означает.
В качестве другого примера, подумайте о Arc
, Это звучит как кривая вокруг круга, но в Rust это означает Atomically Reference Counted
, Если это было написано как ARC
По крайней мере, читатели признают, что это слово является аббревиатурой от чего-то другого, а не от кривой.
Современные программы написаны в основном для читателей. Затем эти правила именования должны быть установлены для удобства чтения человеком, а не для машинной обработки или анализа.
В связи с этим мы теряем читабельность, используя Unesco
над UNESCO
пока ничего не получаю.
И для любых других случаев, я думаю, что просто соблюдение простых правил (или соглашений) аббревиатуры на английском языке достаточно для большинства случаев для лучшей читаемости.
На 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 = [
// ...
];
В дополнение к тому, что сказал @valex, я хочу напомнить пару вещей с данными ответами на этот вопрос.
Я думаю, что общий ответ: это зависит от языка программирования, который вы используете.
С Sharp
Microsoft написала несколько руководств, где кажется, что HtmlButton
это правильный способ назвать класс для этого случая.
Javascript
Javascript имеет некоторые глобальные переменные с аббревиатурами, и он использует их все в верхнем регистре (но, как ни странно, не всегда последовательно), вот несколько примеров:
encodeURIComponent
XMLHttpRequest
toJSON
toISOString
В настоящее время я использую следующие правила:
Заглавные буквы для сокращений:
XMLHTTPRequest
,xmlHTTPRequest
,requestIPAddress
,Верблюжий кейс для аббревиатур:
ID[entifier]
,Exe[cutable]
,App[lication]
,
ID
исключение, извините, но это правда.
Когда я вижу заглавную букву, я предполагаю аббревиатуру, то есть отдельное слово для каждой буквы. Аббревиатуры не имеют отдельных слов для каждой буквы, поэтому я использую случай верблюда.
XMLHTTPRequest
это неоднозначно, но это редкий случай, и это не так многозначно, так что все в порядке, правила и логика важнее красоты.
Об этом немного рассказывает руководство по стилю JavaScript Airbnb. В принципе:
// bad
const HttpRequests = [ req ];
// good
const httpRequests = [ req ];
// also good
const HTTPRequests = [ req ];
Поскольку я обычно читаю заглавную букву как класс, я склонен избегать этого. В конце концов, это все предпочтения.
Отказ от ответственности: английский не мой родной тон. Но я долго думал об этой проблеме, особенно при использовании узла (стиль camelcase) для обработки базы данных, так как имя полей таблицы должно быть змеино, это моя мысль:
Для программиста есть два вида аббревиатур:
- на естественном языке, ЮНЕСКО
- на языке программирования, например,
tmc and textMessageContainer
, который обычно появляется как локальная переменная.
В мире программирования все аббревиатуры на естественном языке должны рассматриваться как слово, причины:
когда мы программируем, мы должны называть переменную в стиле акроним или не в стиле акроним. Итак, если мы назовем функцию getUNESCOProperties, это означает, что ЮНЕСКО является аббревиатурой (в противном случае это не должны быть все прописные буквы), но, очевидно,
get
а такжеproperties
не аббревиатуры. Итак, мы должны назвать эту функцию либо gunescop, либо getUnitedNationsEducationalScientificAndCulturalOrganizationProperties, и то, и другое неприемлемо.естественный язык постоянно развивается, и сегодняшние аббревиатуры станут завтрашними словами, но программы должны быть независимы от этой тенденции и стоять вечно.
кстати, в ответе, получившем наибольшее количество голосов, IO является аббревиатурой в значении компьютерного языка (расшифровывается как InputOutput), но мне не нравится название, так как я думаю, что аббревиатуру (на компьютерном языке) следует использовать только для названия локальная переменная, но класс / функция верхнего уровня, поэтому вместо ввода-вывода следует использовать InputOutput
ЮНЕСКО является особым случаем, так как обычно (на английском языке) читается как слово, а не как аббревиатура - как УЕФА, РАДА, БАФТА и в отличие от BBC, HTML, SSL
Существует также другое соглашение о верблюдах, которое пытается улучшить удобочитаемость для акронимов, используя либо заглавные буквы (HTML
) или строчными (html
), но избегая обоих (Html
).
Так что в вашем случае вы могли бы написать getUNESCOProperties
, Вы могли бы также написать unescoProperties
для переменной, или UNESCOProperties
для класса (соглашение для классов должно начинаться с прописных букв).
Это правило становится сложным, если вы хотите соединить две аббревиатуры, например, для класса с именем XML HTTP Request. Это будет начинаться с заглавной буквы, но так как XMLHTTPRequest
не будет легко читать (это запрос TTP XMLH?), и XMLhttpRequest
нарушил бы соглашение о Camelcase (это XM Lhttp Request?), лучшим вариантом было бы смешать case: XMLHttpRequest
, что на самом деле то, что использовал W3C. Однако использование такого рода наименований не рекомендуется. Для этого примера HTTPRequest
было бы лучшим именем.
Поскольку официальное английское слово для идентификации / идентификации, кажется, ID, хотя это не аббревиатура, вы можете применить там те же правила.
Это соглашение кажется довольно популярным, но это просто соглашение, в котором нет правильного или неправильного. Просто попробуйте придерживаться соглашения и убедитесь, что ваши имена читабельны.