缩略语CamelCase

gal*_*007 226 camelcasing coding-style acronym

我对CamelCase有疑问.你有这个缩写:Unesco = United Nations Educational, Scientific and Cultural Organization.

你应该写: unitedNationsEducationalScientificAndCulturalOrganization

但是如果你需要写首字母缩略词怎么办?就像是:

getUnescoProperties();
Run Code Online (Sandbox Code Playgroud)

用这种方式写它是对的吗? getUnescoProperties() OR getUNESCOProperties();

The*_*Pea 288

从接受的答案中对微软的建议有合理的批评.

  • 根据字符数量对首字母缩写词/首字母缩写词进行不一致的处理:
    • playerIDVS playerIdVS playerIdentifier.
  • 如果两个字母的首字母缩略词出现在标识符的开头,是否仍应大写:
    • USTaxes VS usTaxes
  • 难以区分多个首字母缩略词:
    • USIDvs usId(或parseDBMXML维基百科的例子).

所以我会发布这个答案作为接受答案的替代方案.投票可以决定.所有的首字母缩略词都应该得到一致的处理; 首字母缩略词应该像任何其他词一样对待.引用维基百科:

......有些程序员喜欢将缩写视为小写单词...

所以我重申:OP的问题,我同意接受的答案; 这是对的:getUnescoProperties()

但我想我会在这些例子中得出不同的结论:

  • US TaxesusTaxes
  • Player IDplayerId

如果您认为两个字母的首字母缩略词应该像其他缩略语一样对待,那么请投票给出这个答案.

Camel Case是一种约定,而不是规范.所以我猜流行的意见规则.

在现有代码或标记中搜索"流行"答案时,可能接受的答案是正确的.

  • 1)没有不一致."Id"是**缩写**,而不是首字母缩略词.2)它取决于标识符的上下文,即类,接口,属性,枚举类型,静态字段,参数,方法,属性或事件.如果标识符的指南是使用PascalCase,那么它将是`USTaxes`和`PlayerId`; camelCase:`usTaxes`和`playerId`.3)它是PascalCase中的"USId",camelCase中的"usId"和camelCase中的"parseDbmXml". (25认同)
  • [资本犯罪:如何处理CamelCase中的缩写](http://www.approxion.com/?p=303)的作者在撰写时正确地引用了"憎恶"一词:"虽然[使用大写首字母缩略词]在简单的情况,当一个缩写跟随另一个缩写时,它会导致可恶:HTTPURLConnection,XMLIDREF" (15认同)
  • 你是对的,它是一个缩写.我的观点是它应该是UsTaxes,UsId.两个字母的"缩写或首字母缩略词"不应与三个字母或其他"正常单词"区别对待.来自@ Eonil的答案的其他建议是完全避免缩短.unitedStatesTaxes,或playerIdentifier. (4认同)
  • 哈哈.我怀疑会出现多少混乱 - 但指导原则是防止可能产生混淆的准则.科学语境中一个人为的(坏)缩写示例:`InIN(item)`vs`InIn(item)`(提示:IN是英寸(s)).或者,`IDById(id)`vs`IdById(id)`,context science(提示:ID表示感染性疾病)."两个字符长" - 在哪种情况下? (2认同)
  • 在[微软链接](https://msdn.microsoft.com/en-us/library/141e06ef(V = vs.71)的.aspx)" ......使用Pascal大小写或骆驼案例缩略词*两个以上字符长*....但是,你应该大写由*只有两个字符组成的首字母缩略词*......"这就是我称之为"不一致"的部分.更好的表征是"例外".至少你已经理解了为什么两个字母的首字母缩略词可能会更加混乱.但我猜那些带有"CanCan"的节目只是运气不好; 暧昧是不是舞蹈动作,还是Cercle de l'Aviron de Nantes'社区网络:) (2认同)
  • @Frederik Krautwald:1)有一种观点认为,“ID”(至少最初)是“身份文件”的*首字母缩略词*,在它被劫持还表示“身份”或“身份”之前。2)这是一种自然语言本身不一致的情况(我知道令人震惊),因为即使它是一个*缩写*,几乎所有的缩写都是小写的(如果它们属于“身份”或“身份”不是)*不是*全大写的专有名词。 (2认同)
  • @FrederikKrautwald 当我还是个小伙子时,我读过一篇社论,建议在类型转换函数中始终使用 `as` 作为“魔法词”,如 `asIn()` _[sic]_ 或 `LengthAsIn( )`。IIRC 这与可读性和一致性有关,可能很久以前人们就在编写“InchesFromMeters()”,但还没有人发明“toString()”。说到 JavaScript,我讨厌写 `JSON` 而不是 `Json`,但我会付出一致性的代价。缩写词与首字母缩略词的最大问题是自动转换功能无法识别。 (2认同)
  • @FrederikKrautwald 后来它被 Rust 用作转换操作,并且我知道用简单地称为 `as()` 的模板定义 C++ 类成员...例如:`circle.as<Shape>()` ..但是,是的,我同意,并且我感谢写我多年前读过的这篇文章的人。 (2认同)

Apo*_*ARE 176

微软撰写的一些指导原则camelCase是:

使用首字母缩略词时,请使用Pascal case或camel case作为长度超过两个字符的首字母缩略词.例如,使用HtmlButtonhtmlButton.但是,您应该将仅包含两个字符的首字母缩写词大写,例如System.IO代替System.Io.

不要在标识符或参数名称中使用缩写.如果必须使用缩写,请将camel case用于包含两个以上字符的缩写,即使这与单词的标准缩写相矛盾.

加起来:

  • 当你使用两个字符长的缩写或首字母缩略词时,将它们全部放在大写字母中;

  • 当首字母缩略词长于两个字符时,请为第一个字符使用大写字母.

所以,在你的具体情况下,getUnescoProperties()是正确的.

  • 我不认为这是一个很好的标准.区分正常的首字母缩略词,两个字母的首字母缩略词和正常的单词似乎过于复杂,并且与具有一致命名约定的想法相反. (51认同)
  • 很高兴知道他们遵循自己的准则:[`XMLHttpRequest()`](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest)最初来自微软. (42认同)
  • 此外,由微软声明并没有使"正确"的东西. (37认同)
  • 从技术上讲,"ID"不是首字母缩略词(它是"标识符"或"标识"的缩写),但我真的不知道该指南如何/如果有助于该指南.: - \ (26认同)
  • 我想我应该开始使用`ID`而不是`Id`(我用/看到处都是) (10认同)
  • @Yar,我是在讽刺.我应该更清楚一点,我的意图是笑脸:-). (8认同)
  • MS多么愚蠢的指导方针. (2认同)
  • @Makyen,在这种情况下他们实际上没有.XML是三个字母,因此,根据指南,只有第一个字母应该是大写字母. (2认同)

Eon*_*nil 21

首先,我必须澄清我不是母语为英语的人,所以我对英语语法的主张可能是错误的.如果您发现此类错误,请告诉我,我将非常感激.


首字母缩略词的最佳实践是尽可能避免使用首字母缩略词.无论如何,情况并非如此,因为首字母缩略词UNESCO比全名更熟悉UnitedNationsEducationalScientificAndCulturalOrganization.

然后,我认为UNESCO更有意义,Unesco因为它更接近真实生活形式,因此更加熟悉.我弄清楚这个词Unesco究竟意味着什么.

作为另一个例子,想一想Arc.这听起来像一个圆圈周围的曲线,但在Rust中,这意味着Atomically Reference Counted.如果它被写成ARC,至少读者会认识到这个词是其他东西的缩写,而不是一种曲线.

现代节目主要面向人类读者.然后必须为人类可读性而不是机器处理或分析设置这些命名规则.

从这个角度来看,我们通过使用Unescoover UNESCO而失去了一些可读性.

对于任何其他情况,我认为仅仅遵循简单的英语缩写规则(或惯例)就足以满足大多数情况下的最佳可读性.

  • 上面的例子有点误导."我见过的最好的方法是Apple的...这意味着将缩略词视为一个专有名词......所以联合国教科文组织更有意义" - 这不是你写出专有名词的方式. (4认同)
  • 哇,我很难在答案中找到一句我同意的句子:-) (4认同)

luk*_*k_z 15

getUnescoProperties() 应该是最好的解决方案......

如果可能的话,只要遵循纯粹的camelCase,当你有缩写时,只要在可能的情况下让它们大写,否则就去camelCase.

通常在OO编程变量中应以小写字母(lowerCamelCase)开头,而类应以大写字母(UpperCamelCase)开头.

如果有疑问,只需要纯粹camelCase;)

parseXML很好,parseXml也是camelCase

XMLHTTPRequest对于所有测试案例,它应该是XmlHttpRequest或者xmlHttpRequest没有办法与随后的大写首字母缩略词一起使用,它绝对不明确.

例如,你如何阅读这个词HTTPSSLRequest,HTTP + SSL或者HTTPS + SL(除了......之外没有任何意义),在这种情况下遵循骆驼案例约定,httpSslRequest或者httpsSlRequest,或许它不再是好的,但它肯定更清楚.

  • 我喜欢你的 `HTTPSSSL` 例子,虽然 SL 没有任何意义,但像 HTTPSSHTunnel 这样的东西怎么样?是 HTTPS + SH(shell)还是 HTTP + SSH?谷歌约定绝对不那么模棱两可。 (7认同)

ser*_*inc 13

要转换为CamelCase,还有谷歌(几乎)确定性的Camel案例算法:

从名称的散文形式开始:

  1. 将短语转换为纯ASCII并删除任何撇号.例如,"Müller算法"可能成为"Muellers算法".
  2. 将此结果划分为单词,拆分空格和任何剩余的标点符号(通常为连字符).
    1. 推荐:如果任何单词已经具有常规使用的传统驼峰外观,请将其拆分为其组成部分(例如,"AdWords"变为"广告词").请注意,诸如"iOS"之类的单词本身并不是真正的驼峰; 它违反任何惯例,因此该建议不适用.
  3. 现在小写所有内容(包括首字母缩略词),然后只大写第一个字符:
    1. ......每一个字,产生上骆驼的情况,或
    2. ......除了第一个词之外的每个词,以产生较低的骆驼案例
  4. 最后,将所有单词连接成一个标识符.

请注意,原始单词的大小几乎完全被忽略.

在以下示例中,"XML HTTP请求"正确转换为XmlHttpRequest,XMLHTTPRequest不正确.


val*_*lex 7

在github上有airbnb JavaScript样式指南,有很多明星(此时约为57.5k),并提供有关首字母缩略词的指南:

首字母缩写词和首字母缩写词应始终全部大写,或全部小写.

为什么?名称是为了便于阅读,而不是为了安抚计算机算法.

// 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 = [
  // ...
];
Run Code Online (Sandbox Code Playgroud)

  • "_为什么?名称是为了便于阅读,而不是安抚计算机算法_"所以,```XMLHTTPRequest```比```XmlHttpRequest```更好读,对吧? (6认同)
  • 为什么 `httpRequests` 被认为是好的,而 `HttpRequests` 是坏的,这是没有意义的。遵循这个原则,对于_XML HTTP Request_ 应该是`xmlhttpRequest`??? (6认同)
  • 我经常引用爱彼迎风格指南,但在这种情况下我不同意。我特别不同意他们的说法:“首字母缩略词和首字母缩写词应始终全部大写或全部小写。”。在我看来,“xmlHttpRequest”比“XMLHTTPRequest”更具可读性。 (5认同)

lan*_*nte 5

除了 @valex 所说的之外,我还想用这个问题的给出答案来回顾一下一些事情。

我认为一般答案是:这取决于您使用的编程语言。

C夏普

微软已经编写了一些指南,看起来这HtmlButton是为这种情况命名类的正确方法。

JavaScript

JavaScript 有一些带有首字母缩略词的全局变量,并且全部使用大写(但有趣的是,并不总是一致),这里有一些例子:

encodeURIComponent XMLHttpRequest toJSON toISOString