您是否使用与私有变量相同的约定命名表单上的控件?

时间:2008-08-13 03:17:52

标签: user-interface oop coding-style

出于某种原因,我从未见过这样。有没有理由呢?例如,我喜欢_blah用于私有变量,并且至少在Windows窗体控件中默认是私有成员变量,但是我不记得曾经看到它们以这种方式命名。在我在成员函数中的局部变量中创建/存储控制对象的情况下,具有一些视觉区别特别有用。

11 个答案:

答案 0 :(得分:13)

对于某些人来说,这可能是违反直觉的,但我们对UI元素使用可怕的匈牙利符号。

逻辑很简单:对于任何给定的数据对象,您可能有两个或更多与之关联的控件。例如,您有一个控件,指示文本框中的出生日期,您将拥有:

  • 文本框
  • 表示文本框用于出生日期的标签
  • 允许您选择日期的日历控件

为此,我的标签为lblBirthDate,文本框为txtBirthDate,日历控件为calBirthDate。

但是,我有兴趣听听其他人如何做到这一点。 :)

答案 1 :(得分:4)

匈牙利符号与否,如果人们将m_或_或其他用于标准私有成员变量的内容添加到前面,我会更好奇。

答案 2 :(得分:1)

我个人使用_

为私人对象添加前缀

表单控件总是以类型为前缀, only 原因我这样做是因为intellisense。对于大型表单,只需键入 lbl 并从列表中选择它就可以更容易“获取标签值”^ _ ^它也跟随logic stated by Jon Limjap

虽然这确实是微软.NET编码指南,但请查看here

答案 3 :(得分:1)

对我而言,以私人成员为前缀的命名惯例的大赢家与Intellisense有关。由于下划线在字母表中的任何字母之前,当我执行ctrl-space来调出Intellisense时,我的所有_privateMembers都在顶部。

然而,就命名而言,控制是一个不同的故事。我认为范围是假设的,并且前面几个字母表示类型(例如txtMyGroovyTextbox)因为同样的原因而更有意义;控件按类型分组在Intellisense中。

但是在工作中,它一直是VB,我们做mPrivateMember。我认为m可能代表模块。

答案 4 :(得分:1)

我来自VB并且持有控件的控件类型前缀。我的私人成员使用lower-camel case(firstLetterLowercase),而公共成员使用Pascal / upper-camel case(FirstLetterUppercase)。

如果有太多的标识符/成员/本地人有90%的机会记住/猜测它的名称,那么可能需要更多的抽象。

我从未确信存储类型前缀是有用和/或必要的。但是,我确实养成了遵循我正在使用的任何代码的风格的强烈习惯。

答案 5 :(得分:0)

我从不在变量名中使用下划线。我发现除了alpha(有时是字母数字)字符之外的任何东西都是过量的,除非语言要求。

答案 6 :(得分:0)

我在大写/小写营地(“标题”是私有的,“标题”是公开的),混合了UI组件的“匈牙利”符号(tbTextbox,lblLabel等),我很高兴我们团队中没有Visual Case-Insensitive-Basic开发人员: - )

我不喜欢下划线,因为它看起来有点难看,但我不得不承认它有优势(或者不利,取决于你的观点):在调试器中,所有私有变量都将位于顶部,因为_在字母表顶部。但话说回来,我更喜欢我的私人/公共对在一起,因为这样可以更容易地调试getter / setter逻辑,因为你看到彼此相邻的私有和公共属性,

答案 7 :(得分:0)

我写下他们代表的数据库列的名称。

答案 8 :(得分:0)

我没有,但我很欣赏你的逻辑。我猜大多数人不这样做的原因是,在设计时,下划线在“属性”窗口中看起来有些难看。它还占据了水平空间的额外特征,在这样的停靠窗口中非常珍贵。

答案 9 :(得分:0)

  

匈牙利符号与否,我更多   好奇,如果人们前置m_或_或   他们用于标准私人的任何东西   成员变量。

路,

我使用_前缀作为我的类库对象。由于我说的原因,我专门为UI使用匈牙利表示法。

答案 10 :(得分:-3)

我使用m_作为成员变量,但我越来越倾向于使用lowerCamelCase,就像我对方法参数和局部变量一样。公共资料在UpperCamelCase中。

这似乎是.NET社区中或多或少的公认惯例。