作为一名初级程序员，我正在尝试为自己制定一个标准的命名约定。我意识到这是个人喜好，但我试图从比我聪明得多的你们中的一些人（很多人）那里得到一些想法。
我不是在谈论骆驼符号，而是如何命名变量等。恕我直言，var_Quantity 比 Q 或 varQ 更具描述性。但是，如何防止变量变得太长。我试图在命名我的控件时更具描述性，但我最终得到了一些像“rtxtboxAddrLine1”这样的 RadTextBox，它包含地址行 1。对我来说，这是无法管理的，尽管很清楚该控件是什么。
我只是好奇你是否有一些你遵循的指南，或者我是否留给我自己的设备？
一些基本规则可以在这里找到。更多扩展规则可以在这里找到。这些是来自 Microsoft 框架设计者的官方指南。
至于您的示例，应该简单地调用该变量quantity。
在这种情况下，我认为您最好将其命名为 primaryAddressLine 或 firstAddressLine。这就是为什么 - rtxt 作为前缀无用地告诉您类型。Intellisense 将帮助您确定类型，并且不受对实际对象类型所做的更改的影响。调用它 firstAddressLine 使其远离在变量名称末尾使用 1、2、3... 的（不良）约定，以表明由于某种原因您需要更多它们而不是集合。
将其命名为它所代表的内容/它的解释或使用方式，而不是它的数据类型，并且在命名时，如果您不需要，请不要缩写。
名称指南是最好的起点。但是就像在生活的其他领域一样，一旦你知道了规则，你就会开始知道在哪里打破它们是合理的。
我从不使用旧的匈牙利符号来称呼事物strFirstName,intCount等；但我仍然在控件上使用它：txtFirstName，btnVerifyData等。原因包括：
此外，我很可能对页面或表单上的许多 TextBoxes 或 ComboBoxes 做同样的事情，而我不太可能对页面或表单上引用的所有 int 或字符串做某事。因此，能够快速找到所有带有txt前缀的文本框很有帮助。
不过，即使在这种情况下，也有其他人坚决反对匈牙利语，我相信他们有他们的理由。无论您的个人风格如何，您都可能会发现自己在一个风格迥异的团队中工作。在这种情况下，就做他们该做的；很少值得讨论它。我唯一会这样做是如果他们的风格会导致很多错误，但在我脑海中，我想不出会导致这种情况的案例。
网上有一些很好的编码标准文档 - David Lance 写道： http ://weblogs.asp.net/lhunt/attachment/591275.ashx
我建议您使用 Microsoft 自己的指南作为起点。通常，大多数公司都是从那里开始的（无论如何，根据我的经验）。
http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx
描述性越强越好，您会发现长度并不像记住该控件/变量在五年后所做的那样重要。
对于 .NET API 设计（和一些通用 C# 指南），请查看 Krzysztof Cwalina 和 Brad Abrams 的框架设计指南
问候，坦伯格
我通常会尝试遵循 microsoft 指南，并带有一些非常古老的习惯。
所以，我仍然无法摆脱在 private 前加上下划线 _privateMember 的习惯。
我老了，这已经烧到我的脑海里了。
至于为控件添加前缀，我发现如果描述性太强，在更改 UI 的情况下会变得很痛苦。
例如，您有一个名为 ddlProductLine 的下拉列表，然后必须更改为单选按钮组，您的前缀约定开始比 PITA 更有帮助。
当您有很多小部件要使用时，有时像 uiCtl 这样更通用的前缀可以帮助解决混乱，但如果您必须更改小部件类型，仍然有意义。