这个问题可能看起来很迂腐或者只是愚蠢,但是对于首字母缩略词,你对骆驼套管的做法是什么?你是否坚持认为所有东西,甚至首字母缩略词必须是骆驼套装,或者你是否对缩略语做例外。解释也很棒。我不确定这种做法如何影响IDE功能(自动完成)或行业标准是什么。
答案 0 :(得分:48)
对于C#,请查看Microsoft's guidelines:
将两个字符缩写词的两个字符大写,除了 骆驼套的第一个字 标识符强>
名为DBRate的属性就是一个例子 一个简短的缩写词(DB)用作 帕斯卡尔的第一个字 标识符。一个名为的参数 ioChannel是一个简短的例子 首字母缩写词(IO)用作第一个词 一个骆驼标识符。
只使用三个或更高的首字母大写的第一个字符 除第一个单词外,还有更多字符 一个骆驼标识符。
一个名为XmlWriter的类就是一个例子 用作第一个的长首字母缩略词 Pascal标识符的单词。一个 名为htmlReader的参数是一个 用作长的首字母缩略词的例子 骆驼套的第一个字 标识符
不要将任何首字母缩略词中的任何字符大写,无论如何 他们的长度,在一个开头 骆驼标识符。
名为xmlStream的参数是 使用的长首字母缩略词(xml)的示例 作为骆驼的第一个字 标识符。一个名为的参数 dbServerName是一个简短的例子 首字母缩写词(db)用作第一个词 一个骆驼标识符。
答案 1 :(得分:7)
个人偏好。
我倾向于这样做只是因为与XMLHTTPParser
相比,XmlHttpParser
与其他单词没有很好地融合。做任何让你感觉良好的事情,但要以标准的方式做。
答案 2 :(得分:6)
这就是我喜欢的,这适用于Java:类以大写字母开头,小写字母以小写字母开头,而首字母缩略词不影响它。这导致了这样的事情,
UrlConnection urlConnection;
问题在于,如果你试图应用一个规则,你总是用大写的首字母缩略词,甚至是首字母缩略词的第一个字母而不管它是一个字段或类名,你会得到一些奇怪的东西,比如,
URLConnection URLConnection; // huh?
换句话说,该字段以小写规则开头与假设的大写首字母缩略词规则相矛盾。你不能同时应用它们。
即使是Java SDK也只有一个类名的例子:HttpURLConnection
。您认为它可能是HTTPURLConnection
或HttpUrlConnection
。
答案 3 :(得分:2)
我们没有努力与努力快速统治,但我们一般不用驼峰的缩写词。有少数超过三个字母,但大多数不是。
答案 4 :(得分:2)
一般来说,我们的首字母缩略词是PascalCased或camelCased,正如大多数人所说的那样。
一些例外:
如果会员名称中使用的首字母缩略词在正在编写软件的业务中是众所周知的,并且它是真正的首字母缩略词(大写字母形成字典单词,而不是像初始主义一样XML),我们经常将其大写以避免与字典单词混淆。
有时在针对现有数据库工作的ORM中,我只是将映射变量命名为与DB列,大写和全部相同,而不是必须映射FdicId => FDICID在区分大小写的DB中明确显示。这确实有它的缺点,因为未来的开发人员可以默默地打破功能,如果他们感觉比我更强烈应该正确套装,但不知道为什么。
当在成员名称的末尾使用时,ID有点像翻转者;无论是ID还是Id取决于在类或命名空间中编写第一个此类成员的开发人员,并且很少进行修订。
答案 5 :(得分:1)
一般来说,将缩写词与整个单词大小写相同是最直观的,原因如下。
posix
,unix
,regex
,radar
,scuba
,{{ 1}}和laser
email
,miniiOSLayout
,SSHHTTPSSession
和schemaeBay等技术术语时,它可能会变得视觉上笨拙(授予这些特定示例的是不太可能,他们帮助说明问题)CPUURLLinkC
而不是AClassName
是的,anObjectName
看起来很愚蠢。但是你的代码越多,你就越有可能自己意识到上述几点。虽然本身并不是什么大不了的事情,但很多小事情可能会增加并使你的工作受挫。
答案 6 :(得分:0)
也取决于首字母缩略词的长度。
DB --->看起来不错
openDBConnection
HTTP --->看起来很奇怪
openHTTPCConnection
除了规则:
可读性对我很重要。
一致性表明您在编程方面的努力。
所以,要保持一致和清晰。