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