ChatGPT解决这个技术问题 Extra ChatGPT

CamelCase 中的首字母缩略词 [关闭]

关闭。这个问题是基于意见的。它目前不接受答案。想改进这个问题?更新问题,以便可以通过编辑这篇文章用事实和引用来回答它。 4年前关闭。改进这个问题

我对 CamelCase 有疑问。假设您有这个首字母缩写词:Unesco = United Nations Educational, Scientific and Cultural Organization.

你应该写:unitedNationsEducationalScientificAndCulturalOrganization

但是,如果您需要编写首字母缩写词怎么办?就像是:

getUnescoProperties();

这样写合适吗? getUnescoProperties()getUNESCOProperties();

IMO 转换为 snake_case 揭示了最佳解决方案。你喜欢get_unesco_properties还是get_u_n_e_s_c_o_properties

7
7 revs, 4 users 84%

接受的答案中有对 Microsoft advice 的合理批评。

根据字符数对首字母缩写词/首字母缩写词的处理不一致:

playerID vs playerId vs playerIdentifier。

如果两个字母的首字母缩写词出现在标识符的开头,它们是否仍应大写的问题:

UStaxes 与 usTaxes

难以区分多个首字母缩略词:

即USID vs usId(或Wikipedia示例中的parseDBMXML)。

因此,我将发布此答案作为已接受答案的替代方法。所有首字母缩略词都应一致处理;首字母缩略词应与任何其他词一样对待。 Quoting Wikipedia

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

所以回复:OP的问题,我同意接受的答案;这是正确的:getUnescoProperties()

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

美国税收 → usTaxes

玩家 ID → playerId

因此,如果您认为应该将两个字母的首字母缩略词与其他首字母缩略词一样对待,请投票支持此答案。

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

(编辑:删除投票应该决定这个问题的建议;正如@Brian David 所说;Stack Overflow 不是“人气竞赛”,这个问题被关闭为“基于意见”)

尽管许多人更喜欢将首字母缩略词视为任何其他词,但更常见的做法可能是将首字母缩略词全部大写(即使它会导致“可憎”)

请参阅此 XML 模式中的“EDXML”

请参阅此 XBRL 模式中的“SFAS158”

其他资源:

注意有些人区分缩写和首字母缩略词

注意 Microsoft 指南区分两个字符的首字母缩写词和“长度超过两个字符的首字母缩写词”

请注意,有些人建议完全避免使用缩写词/首字母缩略词

请注意,有些人建议完全避免使用 camelCase / PascalCase

请注意,有些人将“一致性”区分为“内部不一致的规则”(即处理两个字符的首字母缩写词与三个字符的首字母缩写词不同);有些人将“一致性”定义为“一致地应用相同的规则”(即使规则内部不一致)

框架设计指南

微软指南


1) 没有不一致。 “Id”是缩写,而不是首字母缩略词。 2) 取决于标识符的上下文,即类、接口、属性、枚举类型、静态字段、参数、方法、属性或事件。如果标识符的准则是使用 PascalCase,那么它将是 USTaxesPlayerId;驼峰式:usTaxesplayerId。 3) PascalCase 中为 USId,camelCase 中为 usId,camelCase 中为 parseDbmXml
你没看错,是缩写。我的观点是它应该是 UsTaxes,UsId。两个字母的“缩写词或首字母缩略词”不应与三个字母或其他“普通词”区别对待。来自@Eonil 的回答的其他建议是完全避免使用缩短器。 UnitedStatesTaxes 或 playerIdentifier。
哈哈。我怀疑会出现混乱——很多——但这些指导方针是防止可能出现的混乱的指导方针。科学上下文中人为的(错误的)首字母缩略词示例:InIN(item) vs InIn(item)(提示:IN 是英寸)。或者,IDById(id)IdById(id),上下文科学(提示:ID 表示传染病)。 “两个字符长” - 在什么情况下?
Microsoft link "...对于超过两个字符长度的首字母缩略词使用 Pascal 大小写或驼峰大小写。...但是,您应该将仅包含两个字符的首字母缩略词大写 i>...”这就是我所说的“不一致”的部分。更好的表征是“例外”。至少你已经合理化了为什么两个字母的首字母缩写词可能会更加混乱。但我猜那些带有“CanCan”的程序只是不走运。无论是舞蹈动作,还是 Cercle de l'Aviron de Nantes 的社区区域网络,都模棱两可 :)
Capital Offense: How to Handle Abbreviations in CamelCase 的作者在写道:“虽然 [使用大写首字母缩略词] 在简单的情况下有效,但当一个缩写跟随另一个缩写时,它会导致可憎:HTTPURLConnection, XMLIDREF”
A
André Chalella

一些 guidelines Microsoft 撰写的关于 camelCase 的文章包括:

使用首字母缩略词时,对于长度超过两个字符的首字母缩略词,请使用 Pascal 大小写或驼峰大小写。例如,使用 HtmlButton 或 htmlButton。但是,您应该将仅包含两个字符的首字母缩略词大写,例如 System.IO 而不是 System.Io。不要在标识符或参数名称中使用缩写。如果您必须使用缩写,对包含两个以上字符的缩写使用驼峰式大小写,即使这与单词的标准缩写相矛盾。

加起来:

当您使用两个字符长的缩写或首字母缩略词时,请将它们全部大写;

当首字母缩写词超过两个字符时,第一个字符使用大写字母。

因此,在您的具体情况下,getUnescoProperties() 是正确的。


从技术上讲,“ID”不是首字母缩写词(它是“identifier”或“identification”的缩写),但我真的不知道该指南如何/是否有帮助。 :-\
我不认为这是一个好的标准。区分普通首字母缩写词、两个字母的首字母缩写词和普通单词似乎过于复杂,并且与具有一致命名约定的想法背道而驰。
此外,被微软声明并不能做出“正确”的事情。
很高兴知道他们遵循自己的准则:XMLHttpRequest() 最初来自 Microsoft。
@Yar,我在讽刺。通过笑脸,我应该更清楚这是我的意图:-)。
s
serv-inc

要转换为 CamelCase,还有 Google's (nearly) deterministic Camel case algorithm

从名称的散文形式开始:将短语转换为纯 ASCII 并删除所有撇号。例如,“Müller 算法”可能会变成“Muellers 算法”。将此结果划分为单词、空格和任何剩余的标点符号(通常是连字符)。推荐:如果任何单词在常用用法中已经具有常规的驼峰式外观,请将其拆分为其组成部分(例如,“AdWords”变为“广告词”)。请注意,诸如“iOS”之类的词本身并不是真正的驼峰式;它违反了任何惯例,因此该建议不适用。现在小写所有内容(包括首字母缩略词),然后只大写以下字符的第一个字符:......每个单词,产生大写驼峰式,或者......除了第一个单词之外的每个单词,产生小驼峰最后,将所有单词连接成一个标识符。请注意,原始单词的大小写几乎完全被忽略。

在以下示例中,“XML HTTP 请求”正确转换为 XmlHttpRequest,但 XMLHTTPRequest 不正确。


t
teradyl

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

如果可能,只需遵循纯 camelCase,当您有首字母缩略词时,尽可能将它们大写,否则使用 camelCase

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

如有疑问,请纯粹使用 camelCase ;)

parseXML 很好,parseXml 也是 camelCase

XMLHTTPRequest 应该是 XmlHttpRequestxmlHttpRequest 没有办法与后续的大写首字母缩写词一起使用,对于所有测试用例来说肯定都不清楚。

例如,您如何阅读这个词 HTTPSSLRequestHTTP + SSLHTTPS + SL(除了...之外没有任何意义),在这种情况下,请遵循驼峰式大小写约定并选择 httpSslRequesthttpsSlRequest,也许它不再好,但它肯定更清楚。


我喜欢您的 HTTPSSL 示例,尽管 SL 没有任何意义,那么 HTTPSSHTunnel 之类的东西怎么样?是 HTTPS + SH(shell)还是 HTTP + SSH?谷歌约定绝对不那么模棱两可。
v
valex

github 上的 airbnb JavaScript Style Guide 有很多星星(目前约为 57.5k),关于 acronyms 的指南说:

首字母缩写词和首字母缩写词应始终全部大写或全部小写。为什么?名称是为了便于阅读,而不是为了安抚计算机算法。

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

为什么?名称是为了可读性,而不是为了安抚计算机算法”所以,XMLHTTPRequestXmlHttpRequest 更易读,对吧?
为什么 httpRequests 被认为是好的,而 HttpRequests 是坏的,这是没有道理的。那么遵循这个原则,对于 XML HTTP Request 应该是 xmlhttpRequest???
我经常引用 AirBnb 风格指南,但在这种情况下我不同意。我特别不同意他们的说法:“首字母缩写词和首字母缩写词应始终全部大写或全部小写。”。在我看来,xmlHttpRequestXMLHTTPRequest 更具可读性。
你如何看待“LASER”、“RADAR”、“SCUBA”?它们是首字母缩略词,但现在它们被广泛认为是正常的词。
当您使用大写首字母缩写词时,您基本上将其本身转换为一个单词,我认为这是不对的。首字母缩略词应全部大写或小写。
l
lante

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

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

C夏普

Microsoft has written 一些指导方针,其中 HtmlButton 似乎是为这种情况命名类的正确方法。

Javascript

Javascript 有一些带有首字母缩略词的全局变量,并且它都以大写形式使用它们(但有趣的是,并不总是一致)这里有一些示例:

encodeURIComponent XMLHttpRequest toJSON toISOString


嗯,它是 Netscape 的老版本,它甚至有一些没有像 onerror 这样的驼峰式命名法。
我认为您需要第三类项目:首字母缩写词、缩写词和文件扩展名。
F
Fabio says Reinstate Monica

目前我正在使用以下规则:

首字母缩写词大写:XMLHTTPRequest、xmlHTTPRequest、requestIPAddress。驼峰式缩写:ID[entifier]、Exe[cutable]、App[lication]。

ID 是一个例外,很抱歉,但确实如此。

当我看到一个大写字母时,我假设一个首字母缩略词,即每个字母都有一个单独的单词。每个字母的缩写没有单独的单词,所以我使用驼峰式。

XMLHTTPRequest 是模棱两可的,但它是一种罕见的情况,它并没有那么模棱两可,所以没关系,规则和逻辑比美观更重要。


B
Bryantee

JavaScript Airbnb 样式指南 talks a bit about this。基本上:

// bad
const HttpRequests = [ req ];

// good
const httpRequests = [ req ];

// also good
const HTTPRequests = [ req ];

因为我通常会在课堂上阅读前导大写字母,所以我倾向于避免这种情况。归根结底,这都是偏好。


x
xiechao06

免责声明:英语不是我的母语。但是这个问题我想了很久,尤其是在使用节点(驼峰式)处理数据库时,因为表字段的名称应该被蛇化,这是我的想法:

程序员有两种“首字母缩写词”:

自然语言,联合国教科文组织

在计算机编程语言中,例如 tmc 和 textMessageContainer,它们通常以局部变量的形式出现。

在编程世界中,自然语言中的所有首字母缩写词都应该被视为单词,原因是:

当我们编程时,我们应该以首字母缩写形式或非首字母缩写形式命名一个变量。所以,如果我们把一个函数命名为getUNESCOProperties,这意味着UNESCO是一个首字母缩写词(否则它不应该都是大写字母),但显然get和properties不是首字母缩写词。因此,我们应该将此函数命名为 gunescop 或 getUnitedNationsEducationalScientificAndCulturalOrganizationProperties,两者都是不可接受的。自然语言在不断发展,今天的缩略词明天就会变成单词,但程序应该独立于这种趋势,永远屹立不倒。

顺便说一句,在投票最多的答案中,IO 是计算机语言含义中的首字母缩写词(代表 InputOutput),但我不喜欢这个名字,因为我认为首字母缩写词(计算机语言中)应该只用于命名一个局部变量但是一个顶级类/函数,所以应该使用 InputOutput 而不是 IO


“舌头”,而不是“语气”
J
Jesús Carrera

还有另一种驼峰式约定,它试图通过使用大写字母 (HTML) 或小写字母 (html) 来提高首字母缩写词的可读性,但避免同时使用两者 (Html)。

因此,在您的情况下,您可以编写 getUNESCOProperties。您也可以为变量写 unescoProperties,或为类写 UNESCOProperties(类的约定是以大写开头)。

如果您想将两个首字母缩略词放在一起,例如对于名为 XML HTTP Request 的类,此规则会变得很棘手。它会以大写开头,但由于 XMLHTTPRequest 不容易阅读(它是 XMLH TTP 请求吗?),并且 XMLhttpRequest 会破坏驼峰式约定(它是 XM Lhttp 请求吗?),所以最好的选择是混合大小写:XMLHttpRequest,这实际上就是W3C used。但是,不鼓励使用这种命名。对于此示例,HTTPRequest 将是一个更好的名称。

由于标识/身份的官方英文单词似乎是 ID,虽然不是首字母缩略词,但您可以在那里应用相同的规则。

这个约定似乎在那里很流行,但这只是一个约定,没有对错之分。只需尝试遵守约定并确保您的名字可读。


我不相信这整个线程:-) 所以它会是 XMLToHtmlConverter 但 HTMLToXmlConverter?哇...
@JosefSábl,是的,就是这样。关于您的反对意见,我并不是说我喜欢这个约定,但它确实存在。
我将问题读为“在骆驼案例中编写首字母缩写词的良好约定是什么”而不是“您能否列出所有存在的约定”。由于我认为您提到的约定非常糟糕,因此我投了反对票:-)
那么问题是“这样写它正确吗?”,因为有很多“正确”的方式来写它,因为它只是一个约定,而且这个约定很受欢迎(不管你如何看待它),我的答案非常有效:-)
u
user1833431

联合国教科文组织是一个特例,因为它通常(用英语)读成一个单词而不是首字母缩略词 - 像 UEFA、RADA、BAFTA 和 BBC、HTML、SSL 不同


这就是“首字母缩略词”和单纯的“缩写”之间的区别;这种区别似乎与整个讨论有关,但在所提供的答案中几乎完全被忽略了。
BBC、HTML、SSL 和其他您说出每个字母的首字母缩写词更准确地称为首字母缩写词。像 UNESCO 这样发音为一个词的词是真正的首字母缩略词。

关注公众号,不定期副业成功案例分享
关注公众号

不定期副业成功案例分享

领先一步获取最新的外包任务吗?

立即订阅