您在C＃中使用了哪些命名约定？
作为一名初学程序员，我正在努力为自己制定一个标准的命名约定。 我意识到这是个人偏好，但我试图从你们中的一些人（很多人）中得到一些比我更聪明的想法。
我不是在谈论骆驼符号，而是如何命名你的变量等等。恕我直言，var_Quantity比Q或varQ更具描述性。 但是，如何防止变量变得太长。 我试图通过命名我的控件来更具描述性，但我最终得到了一些类似于“rtxtboxAddrLine1”的RadTextBox，其中包含地址行1.对我而言，这是无法管理的，尽管它很清楚该控件是什么。
我只是好奇你是否有一些你遵循的指南，或者我是否离开了自己的设备？
这里可以找到一些基本规则 。 此处可以找到更多扩展规则 。 这些是Microsoft框架设计人员的官方指南。
至于你的例子，变量应该只被称为quantity 。
在这种情况下，我认为你最好将它命名为primaryAddressLine或firstAddressLine。 这就是为什么 – 作为前缀的rtxt无用地告诉你类型。 Intellisense将帮助您处理类型，并且不受对实际对象类型所做的更改的影响。 首先调用它AddressAddress使它远离在变量名末尾使用1,2,3 ……的（差）约定，以表明由于某种原因你需要更多而不是集合。
将它命名为它所代表的内容/它的解释或使用方式不是为了它的数据类型，在命名时它不会缩写，如果你不需要。
名称指南是最佳起点。 但就像在生活的其他方面一样，一旦你了解规则，你就会开始知道打破它们的合理性。
我从不使用调用strFirstName ， intCount之类的旧匈牙利表示法; 但我仍然在控件上使用它： txtFirstName ， btnVerifyData等。原因包括：
- 我不太可能改变控件的类型
- 如果我确实更改了控件的类型，我将不得不更改很多东西，而不仅仅是名称，所以更改名称也没什么大不了的
- 使用Intellisense更容易找到它们。
另外，我很可能对页面或表单上的许多TextBoxes或ComboBox做同样的事情，而我不太可能对页面或表单上引用的所有int或字符串做些什么。 因此，能够快速找到所有带有txt前缀的TextBox有助于它。
不过，还有其他人坚决反对匈牙利人，即使在这种情况下也是如此，我相信他们有理由。 无论您的个人风格如何，您都可能会发现自己在一个风格迥异的团队中工作。 在这种情况下，只做他们做的事情; 它非常非常非常值得提出问题。 我这样做的唯一一次是，如果他们的风格导致了很多错误，但是在我的头脑中，我无法想到导致这种情况的案例。
网上有一些很好的编码标准文件–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的框架设计指南
此致，tamberg
我通常会尝试遵循微软的指导原则，并引入一些非常古老的习惯。
所以，我仍然不能摆脱为私人提供前缀_privateMember的习惯。
我老了，那烧伤了我的大脑。
至于为控件小部件添加前缀，我发现如果你过于描述，那么在将UI改变为轨道的情况下，它会变得很痛苦。
例如，您有一个名为ddlProductLine的下拉列表，然后必须更改为单选按钮组，您的前缀约定开始更多PITA而不是有用。
如果你有很多小部件可以使用，有时像uiCtl这样的更通用的前缀可以帮助解决这个问题，但是如果你必须更改小部件类型仍然有意义。
我喜欢这个文件：
适用于.NET的C＃编码标准 （zip）
它是最佳实践和编码风格指南的良好汇编。