用户界面上的“ ID”或“ Id”


90

我工作的质量检查经理刚刚通知我,我的桌面应用程序中存在一个错误,原因是登录提示应为“ Operator ID”(操作员ID)时出现提示。她的论点是“ Id”指的是弗洛伊德“心理装置”的自我部分,在语义上是不正确的。

现在是一名肛门工程师(AE),我当然必须去查找ID与ID,从我的粗略调查(谷歌)来看,ID似乎和ID一样普遍用于弗洛伊德的自我。

因此,我的推断是,Id是“标识符”的缩写,并且比通常表示两个单词的缩写的ID更正确或至少更常用。

我可以更改UI,但随后我就不会继续担任AE的职业,因此我想知道是否可以使用此类最佳实践或参考来支持我的论点?请记住,此问题与用户界面有关,而不与源代码有关,在这里,缩写词和大小写是哲学的一个完全不同的分支。


6
如果我没记错的话,弗洛伊德实际上是在谈论das es,das ich和das uberich。它翻译为The it,The I(或我)和over-I(或超我)。当将其翻译成英文时,翻译者认为听起来不太好,因此将其翻译成拉丁文(Id,Ego,Super ego),因为听起来更令人印象深刻。
科林·麦凯

5
肛门工程师+1(这个问题实际上很有趣)
Stefano Borini

我曾经问过这个问题,却被遗忘了!但是,我出于个人利益提出了更多要求。
alex

4
您是否提到过在任何地方担任肛门工程师?这和弗赖德决定了这个问题的命运:)。
尤金(Eugene)

那么,您可以指望多少个社区实际上可以算是有趣的地方?:P(+1 btw ^^)
cwap 2010年

Answers:


88

根据Merriam-Webster的缩写,它是“ ID”。如果是正确的缩写,则必须为“ Id”。随着时期。


19
这绝对是正确的答案。即使D本身并不能代表任何东西,我想我们现在都应该意识到英语的异想天开不受逻辑或一致性的束缚。不管好坏,“ ID”是实际的官方正确术语。
约翰Y

1
我什至没有想到要检查字典。鉴于ID被多次定义为Identification的缩写,因此看起来ID确实是正确的。字典编辑者显然需要重新阅读Microsoft的指南。两个和三个字母的缩写。同时,我将UI从ID更改为ID,并接受失败的命令,质量检查。
亚伦·克劳斯顿

8
你们美国人!用真实的英语来说,宫缩没有句号。比较史密斯上校和史密斯军士。或先生,太太和女士的头衔,因为它们是收缩的,所以它们没有句号,而诸如Col.的缩写或诸如Mon.,Tue。和Wed.的缩写确实有句号。
TRiG 2010年

5
跟随:ID是身份的缩写(没有句号),就像电视是电视(或易装癖者)的缩写,也没有句号。没有句号,因为字母并不代表完整的单词。我会在文本中使用ID,在代码中使用ID。
TRiG

1
以我的拙见,这是不正确的:MW网站谈论的是身份证,身份证等身份证件,换句话说(他们的)带有名称和身份的文件,甚至还有图片。显然,数据库表ID(主键)并非如此,它是Identifier的缩写。该点被省略,就像在电视中省略点,或者就此而言,ID(我认为是身份证明文件)一样。
Sklivvz

41

我个人使用“ Id”。编译器不在乎,但我的眼睛在乎。相比:

GetIDByWhatever  <-- looks terrible

GetIdByWhatever  <-- oh so pretty!

在代码方面,美学总是比语法重要。(更新:4年后,我不再支持此声明)


15
谁说我的ID看起来更漂亮?我发现相反。我认为在SO上发布此问题的全部目的是要获得一个合理的,有充分根据的答案。
samvermette 2014年

8
Id在代码中很好(并且我同意,最好),但是问题是关于用户界面的:)您永远不会向用户展示任何一个示例。
肖恩·罗恩


4
这不仅要看起来漂亮,而且例如,如果您想将字符串转换为下划线小写字母,则可以以get_i_d_by_whatevervs结尾get_id_by_whatever
亚当·埃尔索达尼

1
我认为@ErikKinding试图说明的是ID后面紧跟另一个单词。我同意GetID看起来比GetId更好,但是GetIdFromDbTable比GetIDFromDBTable更易于阅读,因为您本能地知道单词在哪里被拆分。
史蒂夫(Steve)

20

'D'并不代表任何东西,因此我一直认为它是缩写,而不是首字母缩写,因此我也使用'Id'而不是'ID'。

我不知道您qa的原因-单词可能具有多种含义-这在英语中并不罕见:)

但是,看起来通常的用法实际上是' ID '(对或错:P),这可能是用户期望的格式。


1
很明显..但是我从来没有做过。+1
womp

3
按照定义,“常用”是正确的。这就是英语的工作方式。是的,ID是正确的。就像电视一样,它是两个字母的缩写。
TRiG 2011年

身份证在现实生活中很常见,主要意思是“身份证明文件” /“身份证明文件” /……您不问某人的身份,而是要提供证明文件。
sanderd17 '19

...过早输入后的后续操作...如果将“ Id”用作“标识符”的简写,则不是在询问文档,因此只是小写的“ d” IMO的缩写。也就是说,在用户界面中使用“ Id”是不好的做法IMO。标识符应该是系统内部使用的东西,最终用户不必知道它。在编程环境中,这是非常常见的缩写,这很好。
sanderd17 '19

5

作为UAUA(超肛门可用性分析师),请使用ID代替ID。

在视觉上,英语更容易识别。在语法上,“ Id”是一个词(与“乌贼”同韵),上面已经给出了弗洛伊德的定义。我们从不口头要求我们出示身份证 ”,而 ”。ID很好,但可以通过,因为句号暗示了多个单词。

所以。

只需使用ID,好吗?

好。


4

质量检查经理的推理思路很愚蠢。许多英语单词具有多种含义。“铅”,“铅”,“铅”(金属,位于正面或位于连接器上)。

我只是想与应用程序其他地方使用的大写字母保持一致。


4

有趣的是,许多人认为应该使用“ Id”。我认为“ ID”是适当的,因为它暗示了我们的发音方式-ID另外,当我在连续的句子中读取“ Id”时,有时我不得不重新读一遍,以确保它不是“是”或“它”。


3

因此,作为技术作家,这是我经常审查别人的工作时遇到的一个问题,无论是程序员,文学士还是其他作家。通常,id是指别人之前在我之前说过的自我,而认同的缩写是ID,只是因为很多人不知道或不了解规则并不意味着他们是正确的(抱歉,直白地说)。您的标点符号和拼写规则在很大程度上与时尚一样多变!

但是,似乎没有人问过,您的公司是否有标准?归根结底,如果您的公司有样式指南,并且他们已在该指南中涵盖了该主题,则应遵循该指南。如果没有涵盖,那么我建议您与维护指南的人员提出问题,并在对话中包括所有利益相关者。一致性是关键。如果您所在的公司没有风格指南,那么也许是时候开始了!

希望这可以帮助...


2

ID =爱达荷州!ID =弗洛伊德!让强迫症开始吧!


1

如果你大声朗读,你会怎么说?我要读两个字母。ID是正确的,类似于类似的缩写,例如TV。(请不要使用圆点,因为字母不能代表任何东西。)

当我处理这样的缩写时,我喜欢用小写大写字母格式化它们,但这只是个人喜好。不管怎么说,首都。

(但我可能会继续在代码本身中使用Id。)


1

用户界面和代码是非常不同的野兽...

“ ID”是用户界面的正确答案。

在代码中,一致性是您的朋友。无论您是否喜欢,都可以使用代码中其他地方已经存在的内容。如果不存在,请阅读并做出决定,或者与团队合作并找到一种大家都可以同意的方法。一致性使生活变得更加轻松。


1

我们所有人都有一点OcD!

无论如何,谷歌风格指南说:

“ ID:不是Id或id,除非是字符串文字或枚举。在某些情况下,最好将其拼写为标识符或标识。”

我要去。

从我能找到的东西来看,微软更加模糊。


0

作为标识符的简短版本,我将使用ID。当您具有以下功能时,也ID这很奇怪

getUserIDByName()

域名方面的多个大写字母对于CamelCase来说是一个很大的问题,因为它们可能会产生歧义,因此会在您的界面和命名中产生同质性


5
当然,您可以只在代码中使用“ getUserIdByName”,并显示带有“ ID”的UI,以获得两全其美的效果。
马修·伊瑟林

1
是的,但这是模棱两可的,尽管我的意思是……您可以忍受=)
Stefano Borini

4
在C#中,约定是在代码中使用带有首字母缩写词的camelCase / PascalCase-例如。上课SqlConnection。但是,在用户界面上,您仍然可以参考“ SQL Server连接详细信息”。
Blorgbeard将于

@Stefano,由于骆驼大小写问题,建议您使用getUserIdByName()而不是getUserIDByName()。但是,我们应该如何处理DB?像:GetDBConnection()?用Db替换DB?
Ofer Zelig


0

我认为这取决于我们的拼写方式。我们不拼写“ it”,而是拼写“ ai-di”。Id-ID是由两个声音拼写而成的,因此人们为了避免将id视为“单词”,所以在帽中打了D号。它更像一个字符符号。我更喜欢“ ID”,只是因为它更好。


0

我更喜欢Id,因为当与其他2个字母的文本一起使用时,它不会变成一个全大写的单词

光伏系统... PVID(一个词还是两个词?)PvId(更清楚)。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.