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

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

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

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

为此,我将具有标签的lbirthdate、文本框的txtbirthdate和日历控件的calbirthdate。

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

不管是不是匈牙利符号,我更想知道人们是否预先准备了m_u或u,或者他们使用的标准私有成员变量。

我个人给私人物品加前缀_

表单控件的前缀始终为类型 只有 我这样做的原因是因为智能感知。对于大型表单,只需键入 LBL 并从列表中选择它,它还遵循 logic stated by Jon Limjap .

尽管这再次符合Microsofts.net编码准则,但请查看它们。 here .

对我来说,给私人成员加下划线的命名约定的巨大胜利与IntelliSense有关。因为字母表中的任何字母前面都有下划线,所以当我使用ctrl空格来显示intellisense时,我所有的私有成员都在上面。

不过,就命名而言,控件是另一回事。我认为范围是假定的,并且为了同样的原因,在前面加几个字母来表示类型(例如,txtmygrouvyTextBox)更有意义;控件按类型以intellisense分组。

但在工作中,它一直是vb,我们做mprivatemember。我想M可能代表模块。

我通过了vb并保留了控件的控件类型前缀。我的私人成员使用小写字母(FirstLetterLowercase),而公共成员使用pascal/大写字母(FirstLetterUppercase)。

如果有太多的标识符/成员/局部变量,有90%的机会记住/猜测它被称为什么,那么可能需要更多的抽象。

我从未相信存储类型前缀是有用和/或必要的。但是,我确实有一个很强的习惯,不管我使用的是什么代码,我都会遵循这种风格。

我没有,但我欣赏你的逻辑。我猜大多数人不这样做的原因是下划线在设计时在属性窗口中看起来有点难看。它还将占用一个额外的水平空间,这是在这样一个停靠窗口溢价。

不管是不是匈牙利符号,我更喜欢 好奇人们是否预先准备好了 无论他们使用什么标准私人 成员变量。

卢克

我对类库对象使用前缀。出于我所说的原因,我专门为用户界面使用匈牙利符号。

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

我在大小写阵营中(“title”是私有的,“title”是公共的),混合了ui组件的“hungarian”符号(tbtextbox、lbllabel等),我很高兴我们团队中没有不区分大小写的可视化基本开发人员:—)

我不喜欢下划线,因为它看起来有点难看,但我必须承认它有一个优点(或缺点,取决于您的观点):在调试器中,所有的私有变量都将位于顶部,因为它们位于字母表的顶部。但是,我还是更喜欢我的私有/公共对在一起,因为这样可以更容易地调试getter/setter逻辑,正如您看到的私有和公共属性相邻一样,

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

我对成员变量使用m_u,但我越来越倾向于像对方法参数和局部变量那样使用lowercamelcase。公共事务是最重要的。

在.NET社区中,这似乎或多或少是被接受的约定。