blocks|key|4712254|text|我想做什么就做什么。通常，您最佳实践是在可读性方面犯错误，而不是遵守某些抽象标准。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4712255|只要保持一致即可。|4712256|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I do what I feel like. In general, your best practice is to err in favor of readability vs. compliance with some abstract standard. 

Just be consistent.

blocks|key|649402|text|Id是一个缩写，而不是首字母缩写，所以我将其命名为“Id”。UI是一个缩写词，而缩写词--无论如何都是简短的--大写为：“UI”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649403|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Id is an abbreviation, not an acronym, so I case it "Id." UI is an acronym, and acronyms--short ones, anyway--get capitalized: "UI."

blocks|key|649322|text|下面是我所做的一个示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649323|id
userId
getUserId|code-block|syntax|javascript|649324|关键是要保持一致。|649325|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Here's a sample of what I do:

<pre><code>id
userId
getUserId
</code></pre>

The key is being consistent.

blocks|key|3869528|text|实际上我更喜欢"ID“。但是，正如每个人所说，一致性是最重要的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3869529|史蒂夫|3869530|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I actually prefer "ID". But, as everyone says, consistency is the most important thing.

Steve

blocks|key|649284|text|Id，与标识符相同。微软建议的命名约定表明，这是推荐的实践，使用代码分析进行编译将支持这一点。如果ID代表分别以I和D开头的两个单词，那么您可以使用ID，并且您确实不应该在参数中使用以小写字母开头的名称。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649285|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Id, as for Identifier. Microsoft's suggested naming conventions indicate that that's the recommended practice and compiling with code analysis will support that.
You would use ID if it stood for two words starting respectively with I and D and you're really not supposed to use names starting with lowercase letters but in parameters.

blocks|key|4712481|text|这并不重要，只要你在整个程序中保持一致即可。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4712482|话虽如此，我还是用"Id“吧。|4712483|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It doesn't matter, just as long as you're consistent throughout your program.

That being said, I'd go with "Id".

blocks|key|649075|text|我也使用camelcase，如果名称以Id结尾，我也会使用它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649076|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I use camelcase, too and I also use it if the name ends with Id.

blocks|key|1183531|text|Id|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1183532|这是我对主观问题的主观回答。|1183533|不过，我已经将其标记为CW。|1183534|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Id

This is my subjective answer for the subjective question. 

I have marked this as CW though.

blocks|key|649341|text|我在所有的表名中都使用了下划线，所以user_id。即使id是独立的，它也都是小写的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649342|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I use underscores in all of my table names, so user_id. Even if id is standalone, it is all lowercase.

blocks|key|4712704|text|我是我会在这里被投票，但我不在乎！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4712705|很明显是id。来自深层的想法！|offset|length|4712706|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Id_Software^0|0|4|2|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

I am I going to be voted down here, but I don't care!

it's obviously <a href="http://en.wikipedia.org/wiki/Id_Software" rel="nofollow noreferrer">id</a>. Ideas from the deep!

blocks|key|1183904|text|它的发音是"eye“，而不是”本我，自我和超我“，所以是id，而不是Id。不管怎样，这就是我的投票。由于它的发音方式，它是一个缩写，而不是一个缩写，这一事实是无关紧要的。它的发音就像是一个缩写词，所以也可以这样键入。哦，驼峰情况是计算史上最糟糕的想法。：)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1183905|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It's pronounced "eye dee", not "id as in id, ego and superego", so ID, not Id. That's my vote, anyhow. The fact that it's an abbreviation, rather than an acronym is irrelevant, due to the way that it's pronounced. It's pronounced as if it were an acronym, so it may as well be typed that way as well. Oh, and camel case is the worst idea in the history of computing.:)

blocks|key|3869790|text|数据库列和对象属性中的ID。参数中的id：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3869791|this.ID+==+id|code-block|syntax|javascript|3869792|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

ID in database columns and object properties. id in parameters:

<pre><code>this.ID == id
</code></pre>

blocks|key|649240|text|我认为可读性是最重要的，如果要让它更容易阅读，就应该覆盖您的约定。我认为，如果你不容易阅读，坚持使用你的枪/惯例是弊大于利的(尽管我们程序员讨厌打破惯例和协议)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649241|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think that readability is of utmost importance, and should override your convention if it's going to make it that much easier to read. I think the cons outweigh the pros for sticking to your guns/convention if you can't read it easily (as much as we programmers hate to break conventions and protocols).

blocks|key|3869572|text|在Machine+SUIF中，Mike+Smith和Glenn+Holloway严格执行大写字母标记新词的案例惯例。因此，尽管CPS是一个缩写，但它是transformToCps而不是transformToCPS。我发现，从长远来看，他们的方法比我们在Quick+C--中的效果更好，在那里我们通常对ID和CPS这样的情况进行所有的caps。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3869573|entityMap|0|LINK|mutability|MUTABLE|url|http://www.eecs.harvard.edu/hube/software/nci/overview.html|1|http://www.cminusminus.org/^0|23|E|2K|E|1|C|0|3I|9|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]|$9|X|A|Y|1|Z]]|E|$]]|$1|F|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

In <a href="http://www.eecs.harvard.edu/hube/software/nci/overview.html" rel="nofollow noreferrer">Machine SUIF</a>, Mike Smith and Glenn Holloway rigidly enforce the case convention that a capital letter marks a new word. So even though CPS is an acronym it's <code>transformToCps</code> and not <code>transformToCPS</code>. I have found that in the long run, their method works better than what we did in <a href="http://www.cminusminus.org" rel="nofollow noreferrer">Quick C--</a>, where we usually did all caps for cases like ID and CPS.

blocks|key|649601|text|FxCop/Code+Analysis会将ID标记为错误的缩写，因此，如果您希望避免禁用规则，则可以出于该原因遵守并使用Id。但是，这真的无关紧要，只要你是始终如一的，正如其他人所指出的那样。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|649602|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

FxCop/Code Analysis will flag ID as being a bad abbreviation, so if you want to avoid disabling a rule, you might conform and use Id for that reason. But again, this really doesn't matter, as long as you are consistent, as has been pointed out by others.

blocks|key|4712769|text|只要你在自己的程序中保持一致，任何你感到舒服的东西都可以。(如果你在一个团队中工作，你应该遵循团队的规则或建立一些规则)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4712770|有一点没有被提及，那就是获得一个好字体的重要性。这将会对你的程序的可读性产生奇妙的影响，而且你的约定问题可能部分是字体问题：|4712771|如果你不能很容易地区分Id和ld+(Id+and+ld)，你应该改变字体，也许字体大小也应该改变。就我个人而言，我喜欢Consolas。|offset|length|style|BOLD|CODE|4712772|entityMap^0|0|0|B|2|E|2|H|B|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|O|8|@$F|P|G|Q|H|I]|$F|R|G|S|H|I]|$F|T|G|U|H|J]]|9|@]|A|$]]|$1|K|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|L|$]]

Whatever you are comfortable with as long as you remain consistent within your own programs. (If you work in a team, you should follow the team's rule or set up some).

One point that hasn't been mentioned is the importance of getting a good font. That will do wonders to your program readability and it could be that your convention problem is partly a font problem:

If you can't easily distinguish Id from ld <code>(Id and ld)</code>, you should to change font and perhaps font size too. Personally, I love Consolas.

blocks|key|1183888|text|我同意其他答案，即最重要的事情是保持一致。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1183889|我要补充的是，如果您的特定代码库没有既定的标准，您应该遵循您的语言或平台设置的约定。在Java中，首字母缩写和其他大写单词的标识符不是大写的：|1183890|id
url
getId()
setUrlParameters()|code-block|syntax|javascript|1183891|在Objective-C中，情况正好相反。您可能有一个小写的"id“或"url”变量，但也有如下类：|1183892|NSURL
NSURLRequest|1183893|因此，在Obj-C中，我会选择如下的方法名称：|1183894|setURLParameters:|1183895|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|Y|8|@]|9|@]|A|$G|H]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I agree with the other answers that the most important thing is to be consistent.

I'd add that, if there isn't an established standard for your particular codebase, you should follow the conventions set by your language or platform. In Java, acronyms and other capitalized words are uncapitalized for identifiers:

<pre><code>id
url
getId()
setUrlParameters()
</code></pre>

In Objective-C, it's the opposite. You might have a lowercase "id" or "url" variable, but you also have classes such as:

<pre><code>NSURL
NSURLRequest
</code></pre>

So in Obj-C I would choose a method name like:

<pre><code>setURLParameters:
</code></pre>

blocks|key|4712364|text|我更喜欢使用ID，在我们公司的标准也是Id优先于Id。如果你觉得ID更容易阅读，我不认为使用ID有问题。编译器并不关心:)我在模式Id列中使用了相同的约定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4712365|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I prefer to use Id and in our company the standard is also Id over ID. I don't think there is a problem using ID if you find it easier to read. The compiler doesn't care :) I use the same convention in my schema Id columns.

blocks|key|3869449|text|不同的语言有不同的指导原则。对于.NET，您可以阅读Framework+Design+Guidelines:+Conventions,+Idioms,+and+Patterns+for+Reusable+.NET+Libraries。对于Java，你可以阅读Code+Conventions+for+the+Java+Programming+Language。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3869450|entityMap|0|LINK|mutability|MUTABLE|url|https://rads.stackoverflow.com/amzn/click/com/0321545613|1|http://java.sun.com/docs/codeconv/^0|Q|2I|0|3L|1E|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

Different languages have different guidelines. For .NET you may read <a href="https://rads.stackoverflow.com/amzn/click/com/0321545613" rel="nofollow noreferrer" rel="nofollow noreferrer">Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries</a>. For Java you may read <a href="http://java.sun.com/docs/codeconv/" rel="nofollow noreferrer">Code Conventions for the Java Programming Language</a>.

blocks|key|1183921|text|"Id“不明确。它是人类心理的“自我”/“超我”模型的一部分吗？可能不是:您可能正在尝试缩写一个单词，比如"Identity“、"Identifier”或“Identifier”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1183922|通过确定你的意思来消除歧义(和大小写问题)，然后不要缩写。|offset|length|style|BOLD|1183923|entityMap^0|0|O|4|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

"Id" is ambiguous. Is it part of the "ego" / "superego" model of the human psyche? Probably not: you probably are trying to abbreviate a word, like "Identity" or "Identification" or "Identifier". 

Get rid of the ambiguity (and the casing question) by deciding what you mean and then don't abbreviate.

I use <code>camelCase</code> in my code and database field names, etc, but with fields that have <code>Id</code> at the end, it always ends up being hard to read. For example, <code>itemId</code>, <code>teacherId</code>, <code>unitId</code>, etc. In these cases I consider breaking convention and writing <code>itemID, teacherID, or unitID</code> just for improved readability.

What do you do and what's a general, best practice of dealing with this issue?

ID, id, or Id?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我在代码和数据库字段名等中使用了camelCase，但是如果字段末尾有Id，结果总是很难读懂。例如，itemId、teacherId、unitId等。在这些情况下，我认为编写itemID, teacherID, or unitID只是为了提高可读性。你是做什么的，处理这个问题的一般最佳实践是什么？

问ID、id还是Id？
EN

回答 20

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ID、id还是Id？EN

回答 20

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ID、id还是Id？
EN