Сокращения в 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.
  • Вопрос о том, должны ли двухбуквенные аббревиатуры быть заглавными, если они появляются в начале идентификатора:
    • USTaxes против usTaxes
  • Сложность в различении нескольких сокращений:
    • то есть USID против usId (или parseDBMXML в примере из Википедии).

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

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

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

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

  • US TaxesusTaxes
  • Player IDplayerId

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

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

(ОБНОВЛЕНИЕ: Убрав это предположение, что голосование должно решить эту проблему; как говорит @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 (почти) детерминированный алгоритм использования верблюдов:

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

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

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

В следующих примерах "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, который обычно отображается как локальная переменная.

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

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

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

кстати, в ответе с наибольшим количеством голосов 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 будет лучшим именем.

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

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