6

作为一名初级程序员,我正在尝试为自己制定一个标准的命名约定。我意识到这是个人喜好,但我试图从比我聪明得多的你们中的一些人(很多人)那里得到一些想法。

我不是在谈论骆驼符号,而是如何命名变量等。恕我直言,var_Quantity 比 Q 或 varQ 更具描述性。但是,如何防止变量变得太长。我试图在命名我的控件时更具描述性,但我最终得到了一些像“rtxtboxAddrLine1”这样的 RadTextBox,它包含地址行 1。对我来说,这是无法管理的,尽管很清楚该控件是什么。

我只是好奇你是否有一些你遵循的指南,或者我是否留给我自己的设备?

4

8 回答 8

12

一些基本规则可以在这里找到更多扩展规则可以在这里找到。这些是来自 Microsoft 框架设计者的官方指南。

至于您的示例,应该简单地调用该变量quantity

于 2008-11-20T21:33:25.093 回答
5

在这种情况下,我认为您最好将其命名为 primaryAddressLine 或 firstAddressLine。这就是为什么 - rtxt 作为前缀无用地告诉您类型。Intellisense 将帮助您确定类型,并且不受对实际对象类型所做的更改的影响。调用它 firstAddressLine 使其远离在变量名称末尾使用 1、2、3... 的(不良)约定,以表明由于某种原因您需要更多它们而不是集合。

将其命名为它所代表的内容/它的解释或使用方式,而不是它的数据类型,并且在命名时,如果您不需要,请不要缩写。

于 2008-11-20T21:36:43.010 回答
5

名称指南是最好的起点。但是就像在生活的其他领域一样,一旦你知道了规则,你就会开始知道在哪里打破它们是合理的。

我从不使用旧的匈牙利符号来称呼事物strFirstName,intCount等;但我仍然在控件上使用它:txtFirstNamebtnVerifyData等。原因包括:

  • 我不太可能更改控件的类型
  • 如果我确实更改了控件的类型,我将不得不更改很多东西,而不仅仅是名称,所以更改名称也没什么大不了的
  • 使用 Intellisense 更容易找到它们。

此外,我很可能对页面或表单上的许多 TextBoxes 或 ComboBoxes 做同样的事情,而我不太可能对页面或表单上引用的所有 int 或字符串做某事。因此,能够快速找到所有带有txt前缀的文本框很有帮助。

不过,即使在这种情况下,也有其他人坚决反对匈牙利语,我相信他们有他们的理由。无论您的个人风格如何,您都可能会发现自己在一个风格迥异的团队中工作。在这种情况下,就做他们该做的;很少值得讨论它。我唯一会这样做是如果他们的风格会导致很多错误,但在我脑海中,我想不出会导致这种情况的案例。

于 2008-11-20T21:57:03.517 回答
2

网上有一些很好的编码标准文档 - David Lance 写道: http ://weblogs.asp.net/lhunt/attachment/591275.ashx

于 2008-11-20T21:29:25.240 回答
2

我建议您使用 Microsoft 自己的指南作为起点。通常,大多数公司都是从那里开始的(无论如何,根据我的经验)。

http://msdn.microsoft.com/en-us/library/czefa0ke(VS.71).aspx

于 2008-11-20T21:36:27.817 回答
1

描述性越强越好,您会发现长度并不像记住该控件/变量在五年后所做的那样重要。

于 2008-11-20T21:28:00.250 回答
1

对于 .NET API 设计(和一些通用 C# 指南),请查看 Krzysztof Cwalina 和 Brad Abrams 的框架设计指南

问候,坦伯格

于 2008-11-20T21:36:12.200 回答
1

我通常会尝试遵循 microsoft 指南,并带有一些非常古老的习惯。
所以,我仍然无法摆脱在 private 前加上下划线 _privateMember 的习惯。
我老了,这已经烧到我的脑海里了。

至于为控件添加前缀,我发现如果描述性太强,在更改 UI 的情况下会变得很痛苦。

例如,您有一个名为 ddlProductLine 的下拉列表,然后必须更改为单选按钮组,您的前缀约定开始比 PITA 更有帮助。

当您有很多小部件要使用时,有时像 uiCtl 这样更通用的前缀可以帮助解决混乱,但如果您必须更改小部件类型,仍然有意义。

于 2008-11-20T21:44:01.933 回答