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

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

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

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

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

поэтому я повторяю вопрос ОП, я согласен с принятым ответом; это правильно:getUnescoProperties()

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

• US Taxes → usTaxes
• Player ID → playerId

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

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

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

• см. "EDXML" в этом XML schema
• см. "SFAS158" в этом по XBRL-схемы

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

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

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

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

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

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

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

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

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

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

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

parseXML - штраф, parseXml тоже camelCase

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

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

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

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

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

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

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

здесь руководство по стилю JavaScript airbnb в github с большим количеством звезд (~57.5 k в данный момент) и руководствами о сокращения что сказать:

сокращения людях. всегда должно быть все с большой буквы, или все в нижнем регистре.

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

// 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 = [
  // ...
];

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

1. заглавный случай для аббревиатур:XMLHTTPRequest, xmlHTTPRequest, requestIPAddress.

2. Верблюжий чехол для аббревиатур:ID[entifier], Exe[cutable], App[lication].

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

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

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

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

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

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