У меня есть сомнения по поводу CamelCase. Предположим, у вас есть эта аббревиатура:Unesco = United Nations Educational, Scientific and Cultural Organization.
Вы должны написать: unitedNationsEducationalScientificAndCulturalOrganization
Но что, если вам нужно написать акроним? Что-то вроде:
getUnescoProperties();
Правильно ли так написать? getUnescoProperties() OR getUNESCOProperties();
coding-style
camelcasing
acronym
gal007
источник
источник
get_unesco_properties
илиget_u_n_e_s_c_o_properties
?Ответы:
Вот некоторые рекомендации, которые Microsoft написала
camelCase
:Подводя итог:
Когда вы используете аббревиатуру или аббревиатуру длиной два символа, поместите их все в прописные буквы;
Если аббревиатура длиннее двух символов, используйте заглавную букву для первого символа.
Так что, в вашем конкретном случае
getUnescoProperties()
это правильно.источник
ID
вместо этогоId
(который я использую / вижу везде)XMLHttpRequest()
изначально пришли от Microsoft.Есть обоснованная критика совета Microsoft из принятого ответа.
playerID
противplayerId
противplayerIdentifier
.USTaxes
противusTaxes
USID
противusId
(илиparseDBMXML
в примере Википедии).Поэтому я опубликую этот ответ как альтернативу принятому ответу. Все аббревиатуры должны рассматриваться последовательно; аббревиатуры следует трактовать как любое другое слово. Цитируя Википедию :
Итак, вопрос OP: я согласен с принятым ответом; это верно:
getUnescoProperties()
Но я думаю, что я бы пришел к другому выводу в этих примерах:
US Taxes
→usTaxes
Player ID
→playerId
Поэтому проголосуйте за этот ответ, если считаете, что двухбуквенные аббревиатуры следует рассматривать как другие аббревиатуры.,Случай с верблюдом - это соглашение, а не спецификация. Так что я думаю, что популярные правила мнения.( РЕДАКТИРОВАТЬ: удаление этого предложения о том, что голосование должно решить эту проблему; как говорит @Brian David; Stack Overflow не является «конкурсом популярности», и этот вопрос был закрыт как «основанный на мнении»)
Несмотря на то, что многие предпочитают относиться к аббревиатурам как к любому другому слову, более распространенная практика может заключаться в том, чтобы ставить аббревиатуры в заглавные буквы (даже если это приводит к «мерзостям»).
Другие источники:
источник
USTaxes
иPlayerId
; camelCase:usTaxes
иplayerId
. 3) Это будетUSId
в PascalCase,usId
в camelCase иparseDbmXml
в camelCase.InIN(item)
vsInIn(item)
(подсказка: IN - дюйм (-ы)). ИлиIDById(id)
противIdById(id)
контекстной науки (подсказка: ID означает инфекционное заболевание). «Два символа длиной» - что в каком контексте?Во-первых, я должен уточнить, что я не являюсь носителем английского языка , поэтому мое утверждение о грамматике английского языка может быть просто неверным. Если вы обнаружите такие ошибки, пожалуйста, дайте мне знать, и я буду очень благодарен.
Лучшая практика для аббревиатуры будет избегать сокращений в максимально возможной степени. Во всяком случае, это не так, потому что аббревиатура
UNESCO
более знакома, чем полное имяUnitedNationsEducationalScientificAndCulturalOrganization
.Тогда, я думаю, что это
UNESCO
имеет больше смысла, чемUnesco
просто потому, что это ближе к реальной жизни, поэтому более знакомо. У меня были некоторые проблемы, чтобы понять, что наUnesco
самом деле означает это слово .В качестве другого примера подумайте
Arc
. Это звучит как кривая вокруг круга, но в Rust это означаетAtomically Reference Counted
. Если бы оно было написано такARC
, по крайней мере, читатели признали бы, что слово является аббревиатурой от чего-то другого, а не от кривой.Современные программы написаны в основном для читателей. Затем эти правила именования должны быть установлены для удобства чтения человеком, а не для машинной обработки или анализа.
С этой точки зрения мы теряем читабельность, используя
Unesco
over,UNESCO
но ничего не получая.И для любых других случаев, я думаю, что простого соблюдения простых правил (или соглашений) аббревиатуры на английском языке достаточно для большинства случаев для лучшей читабельности .
источник
Чтобы преобразовать в CamelCase, есть также (почти) детерминистический алгоритм случая с верблюдом от Google :
В следующих примерах «XML-HTTP-запрос» правильно преобразуется в XmlHttpRequest, XMLHTTPRequest неверен.
источник
getUnescoProperties()
должно быть лучшим решением ...Когда это возможно, просто следуйте чистому
camelCase
, когда у вас есть аббревиатуры, просто по возможности пишите их в верхнем регистре, иначеcamelCase
.Обычно в программировании ОО переменные должны начинаться с буквы нижнего регистра (
lowerCamelCase
), а класс должен начинаться с буквы верхнего регистра (UpperCamelCase
).Когда сомневаешься, просто становись чистым
camelCase
;)parseXML
хорошо,parseXml
такжеcamelCase
XMLHTTPRequest
Должен бытьXmlHttpRequest
илиxmlHttpRequest
нет способ идти с последующими прописными аббревиатурами, это окончательно не ясно для всех тестовых случаев.например, как вы читаете это слово
HTTPSSLRequest
,HTTP + SSL
илиHTTPS + SL
(это ничего не значит, кроме ...), в этом случае следуйте условию верблюжьего случая и продолжайте,httpSslRequest
илиhttpsSlRequest
, может быть, это уже не приятно, но это определенно более ясно.источник
HTTPSSL
пример, хотя SL ничего не значит, а как насчет HTTPSSHTunnel? Это HTTPS + SH (оболочка) или HTTP + SSH? Соглашение Google определенно менее неоднозначно.На github есть airbnb JavaScript Style Guide с большим количеством звездочек (~ 57,5 тыс. На данный момент) и руководства по акронимам, которые говорят:
источник
XMLHTTPRequest
лучше читаем, чемXmlHttpRequest
, верно?httpRequests
считается хорошим, ноHttpRequests
плохим. следуя этому принципу тогда, для XML HTTP Request должен бытьxmlhttpRequest
???xmlHttpRequest
более читабельно, чемXMLHTTPRequest
на мой взгляд.В настоящее время я использую следующие правила:
Капитал случае аббревиатур:
XMLHTTPRequest
,xmlHTTPRequest
,requestIPAddress
.Camel случае сокращений:
ID[entifier]
,Exe[cutable]
,App[lication]
.ID
исключение, извините, но это правда.Когда я вижу заглавную букву, я предполагаю аббревиатуру, то есть отдельное слово для каждой буквы. Аббревиатуры не имеют отдельных слов для каждой буквы, поэтому я использую случай верблюда.
XMLHTTPRequest
это неоднозначно, но это редкий случай, и это не так многозначно, так что все в порядке, правила и логика важнее красоты.источник
Руководство по стилю JavaScript Airbnb немного говорит об этом . В принципе:
Поскольку я обычно читаю заглавную букву как класс, я склонен избегать этого. В конце концов, это все предпочтения.
источник
В дополнение к тому, что сказал @valex, я хочу напомнить пару вещей с данными ответами на этот вопрос.
Я думаю, что общий ответ: это зависит от языка программирования, который вы используете.
С Sharp
Microsoft написала несколько руководящих принципов, в которых кажется, что
HtmlButton
это правильный способ назвать класс для этих случаев.Javascript
Javascript имеет некоторые глобальные переменные с аббревиатурами, и он использует их все в верхнем регистре (но, как ни странно, не всегда последовательно), вот несколько примеров:
encodeURIComponent
XMLHttpRequest
toJSON
toISOString
источник
onerror
.Отказ от ответственности: английский не мой родной тон. Но я долго думал об этой проблеме, особенно при использовании узла (стиль camelcase) для обработки базы данных, так как имя полей таблицы должно быть змеино, это моя мысль:
Для программиста есть два вида аббревиатур:
tmc and textMessageContainer
, который обычно отображается в виде локальной переменной.В мире программирования все аббревиатуры на естественном языке должны рассматриваться как слово , причины:
когда мы программируем, мы должны называть переменную либо в стиле акроним, либо в стиле не акроним. Итак, если мы назовем функцию getUNESCOProperties, это означает, что ЮНЕСКО является аббревиатурой (в противном случае это должны быть не все прописные буквы), но, очевидно,
get
иproperties
не являются аббревиатурами. поэтому мы должны назвать эту функцию либо gunescop, либо getUnitedNationsEducationalScientificAndCulturalOrganizationProperties , и то, и другое неприемлемо.естественный язык постоянно развивается, и сегодняшние аббревиатуры станут словами завтра , но программы должны быть независимы от этой тенденции и стоять вечно.
кстати, в ответе с наибольшим количеством голосов 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, хотя это не аббревиатура, вы можете применить там те же правила.
Это соглашение кажется довольно популярным, но это просто соглашение, в котором нет правильного или неправильного. Просто попробуйте придерживаться соглашения и убедитесь, что ваши имена читабельны.
источник