Сокращения в CamelCase [закрыто]

243

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

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

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

getUnescoProperties();

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

gal007
источник
2
Разве это не должно быть на программистах. SE?
Pacerier
5
Преобразование IMO в snake_case показывает лучшее решение. Вам нравится get_unesco_propertiesили get_u_n_e_s_c_o_properties?
июня
Похожие вопросы: stackoverflow.com/questions/4504508/camel-casing-acronyms
Антон Тарасенко

Ответы:

195

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

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

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

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

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

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

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

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ Apollo
источник
11
Я думаю, что я должен начать использовать IDвместо этого Id(который я использую / вижу везде)
jasonscript
30
Технически «ID» не является аббревиатурой (это аббревиатура «идентификатора» или «идентификации»), но я действительно не знаю, как / если это руководство помогает с этим. : - \
Брайант
64
Я не думаю, что это хороший стандарт. Различение нормальных сокращений, двухбуквенных сокращений и обычных слов кажется слишком сложным и противоречит идее согласованного именования.
Сэм
40
Кроме того, заявление Microsoft не делает что-то «правильное».
Сэм
48
Приятно знать, что они следуют своему собственному руководству: XMLHttpRequest()изначально пришли от Microsoft.
Макьен
315

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

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

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

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

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

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

  • US TaxesusTaxes
  • Player IDplayerId

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

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

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

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

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

  • Обратите внимание, что некоторые люди различают аббревиатуру и аббревиатуру
  • Примечание. В рекомендациях Microsoft проводится различие между двухбуквенными аббревиатурами и «аббревиатурами длиной более двух символов».
  • Обратите внимание, что некоторые люди рекомендуют избегать сокращений / аббревиатур вообще
  • Обратите внимание, что некоторые люди рекомендуют вообще избегать использования CamelCase / PascalCase
  • Обратите внимание, что некоторые люди различают «согласованность» как «правила, которые кажутся внутренне непоследовательными» (т. Е. Трактуют аббревиатуры из двух символов, отличные от аббревиатур из трех символов); некоторые люди определяют «последовательность» как «последовательно применяя одно и то же правило» (даже если правило внутренне несовместимо)
  • Руководство по проектированию рамок
  • Руководство Microsoft
The Red Pea
источник
26
1) Нет противоречий. «Id» - это сокращение , а не аббревиатура. 2) Это зависит от контекста идентификатора, то есть класса, интерфейса, атрибута, типа перечисления, статического поля, параметра, метода, свойства или события. Если указатель для идентификатора использует PascalCase, то это будет USTaxesи PlayerId; camelCase: usTaxesи playerId. 3) Это будет USIdв PascalCase, usIdв camelCase и parseDbmXmlв camelCase.
Фредерик Краутвальд
6
Вы правы, это аббревиатура. Я хочу сказать, что это должны быть UsTaxes, UsId. Двухбуквенное «сокращение или аббревиатура» не следует трактовать иначе, чем трехбуквенные или другие «нормальные слова». Другой совет, из ответа @ Eonil, заключается в том, чтобы вообще избегать укорачивателей. unitedStatesTaxes или playerIdentifier.
Красный горох
3
Ха ха Я сомневаюсь, что путаница возникнет - много - но руководящие принципы, ну, в общем, руководящие принципы, чтобы предотвратить возможную путаницу. Придуманный (плохой) пример аббревиатуры в научном контексте: InIN(item)vs InIn(item)(подсказка: IN - дюйм (-ы)). Или IDById(id)против IdById(id)контекстной науки (подсказка: ID означает инфекционное заболевание). «Два символа длиной» - что в каком контексте?
Фредерик Краутвальд
2
По ссылке Microsoft "... используйте регистр Pascal или верблюд для аббревиатур длиной более двух символов ... Однако вы должны использовать заглавные буквы, состоящие всего из двух символов ..." Это та часть, которую я бы назвал "непоследовательной ». Лучшая характеристика "исключение". И, по крайней мере, вы объяснили, почему двухбуквенные аббревиатуры могут быть более запутанными. Но я думаю, что этим программам с «CanCan» просто не повезло; неоднозначно, будь то танцевальный ход или сеть сообщества сообщества Cercle de l'Aviron de Nantes :)
The Red Pea
18
Автор Capital Offense: Как обрабатывать сокращения в CamelCase правильно вызывает термин «мерзость», когда пишет: «Хотя [использование прописных сокращений] работает в простых случаях, это приводит к мерзостям, когда одно сокращение следует за другим: HTTPURLConnection, XMLIDREF»
kghastie
21

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


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

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

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

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

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

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

Eonil
источник
4
Приведенные выше примеры немного вводят в заблуждение. «Лучший подход, который я когда-либо видел, был у Apple ... Это означает, что трактовать аббревиатуры как собственно существительное ... Так что ЮНЕСКО имеет больше смысла» - это не то, как вы пишете правильные существительные.
Микко Рантанен
@MikkoRantanen Я обновил свой ответ.
Эонил
7
Ничего себе я не могу найти предложение в этом ответе, с которым я бы согласился :-)
Йозеф Сабл
Это полностью зависит от контекста кода, над которым вы работаете, имеют ли аббревиатуры / аббревиатуры более или менее смысл. Например, я работаю в сфере финансов, и существует так много уникальных терминов, которые одинаковы во всей отрасли и на самом деле во всем мире. Вы бы напрасно тратили время и создавали ненужное многословие, не используя аббревиатуры, которые наизусть знают все, кто будет работать в этой компании. Например, PV для текущей стоимости, FV для будущей стоимости, среднее значение для среднего значения, exp для показателя степени и т. Д.
Will
@ pm100 Разве это не то, что я сказал? ЮНЕСКО не так, как вы пишете собственные имена.
Микко Рантанен
17

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

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

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

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

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

Serv-вкл
источник
17

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

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

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

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

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

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

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

luk_z
источник
2
Мне нравится ваш HTTPSSLпример, хотя SL ничего не значит, а как насчет HTTPSSHTunnel? Это HTTPS + SH (оболочка) или HTTP + SSH? Соглашение Google определенно менее неоднозначно.
Л. Холанда
10

На 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 = [
  // ...
];
Валлекс
источник
7
« Почему? Имена предназначены для читабельности, а не для умиротворения компьютерного алгоритма », поэтому XMLHTTPRequestлучше читаем, чем XmlHttpRequest, верно?
Л. Холанда
2
Не имеет смысла, почему httpRequestsсчитается хорошим, но HttpRequestsплохим. следуя этому принципу тогда, для XML HTTP Request должен быть xmlhttpRequest???
Л. Холанда
1
Я часто цитирую руководство по стилю AirBnb, но в этом случае я не согласен. Я особенно не согласен с их утверждением: «Акронимы и инициализмы всегда должны быть прописными или строчными». xmlHttpRequestболее читабельно, чем XMLHTTPRequestна мой взгляд.
Ронан
3

В настоящее время я использую следующие правила:

  1. Капитал случае аббревиатур: XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

  2. Camel случае сокращений: ID[entifier], Exe[cutable], App[lication].

ID исключение, извините, но это правда.

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

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

user2992258
источник
1

Руководство по стилю JavaScript Airbnb немного говорит об этом . В принципе:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

Поскольку я обычно читаю заглавную букву как класс, я склонен избегать этого. В конце концов, это все предпочтения.

Bryantee
источник
1

В дополнение к тому, что сказал @valex, я хочу напомнить пару вещей с данными ответами на этот вопрос.

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

С Sharp

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

Javascript

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

encodeURIComponent XMLHttpRequest toJSON toISOString

Lante
источник
Ну, это Netscape старый, даже есть некоторые без CamelCase, как onerror.
Эдди
1

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

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

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

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

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

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

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

xiechao06
источник
«язык», а не «тон»
Дан Даскалеску
0

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

user1833431
источник
1
Это и есть различие между «аббревиатурами» и простыми «аббревиатурами»; это различие, по-видимому, относится ко всей дискуссии, но почти полностью исключено из представленных ответов.
Симон
BBC, HTML, SSL и другие аббревиатуры, где вы произносите каждую букву, более точно называются инициализмами. Такие слова, как ЮНЕСКО, которые произносятся как слова, являются настоящими аббревиатурами.
Lrdwhyt
-2

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

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

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

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

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

Хесус Каррера
источник
3
Я не верю, что весь этот поток :-) Так что это будет XMLToHtmlConverter, но HTMLToXmlConverter? Вау ...
Йозеф Сабл
1
@ JosefSábl, да, так и будет. Что касается вашего отрицательного голоса, я не говорю, что мне нравится это соглашение, но оно определенно существует.
Хесус Каррера
1
Я прочитал вопрос как «Что такое хорошее соглашение написания Акронимов в случае верблюда», а не «Можете ли вы перечислить все существующие соглашения». И так как я считаю вашу упомянутую конвенцию очень плохой, я понизил голосование :-)
Йозеф Сабл
Ну, вопрос в том, «Правильно ли это писать так?», И поскольку существует много «правильных» способов написать это, потому что это просто соглашение, и это соглашение довольно популярно (независимо от того, как вы его считаете), мой Ответ очень действителен :-)
Хесус Каррера