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

Posted 2023-03-25

【中文标题】您是不是使用与私有变量相同的约定来命名表单上的控件？

【英文标题】：Do you name controls on forms using the same convention as a private variable?您是否使用与私有变量相同的约定来命名表单上的控件？

【发布时间】：2010-09-05 18:48:36

【问题描述】：

出于某种原因，我从未见过这样做过。有理由不这样做吗？例如，我喜欢 _blah 作为私有变量，至少在 Windows 窗体中，控件默认是私有成员变量，但我不记得曾经见过它们以这种方式命名。如果我在成员函数内的局部变量中创建/存储控制对象，那么有一些视觉上的区别是特别有用的。

【参考方案1】：

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

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

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

为此，我将 lblBirthDate 用于标签，txtBirthDate 用于文本框，calBirthDate 用于日历控件。

不过，我很想听听其他人是如何做到这一点的。 :)

【参考方案2】：

无论是否使用匈牙利符号，我都很好奇人们是否将 m_ 或 _ 或任何他们用于标准私有成员变量的东西放在前面。

【参考方案3】：

我个人在私有对象前加上 _

表单控件总是以类型为前缀，唯一我这样做的原因是因为智能感知。对于大型表单，只需键入 lbl 并从列表中选择它就可以更轻松地“获取标签值”^_^ 它也遵循logic stated by Jon Limjap。

虽然这确实再次出现在 Microsoft 的 .NET 编码指南中，但请查看 here。

【参考方案4】：

对我来说，在私有成员前加下划线的命名约定的重大胜利与 Intellisense 相关。由于下划线位于字母表中的任何字母之前，因此当我使用 ctrl-space 调出 Intellisense 时，我的所有 _privateMembers 都位于顶部。

但是，就命名而言，控件是另一回事。我认为这个范围是假设的，并且在前面加上几个字母来表示类型（例如txtMyGroovyTextbox）出于同样的原因更有意义；控件在 Intellisense 中按类型分组。

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

【参考方案5】：

我是通过 VB 来的，并坚持使用控件的控件类型前缀。我的私人成员使用小写字母 (firstLetterLowercase)，而公共成员使用 Pascal/大写字母 (FirstLetterUppercase)。

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

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

【参考方案6】：

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

【参考方案7】：

匈牙利符号与否，我更喜欢 好奇人们是否在前面加上 m_ 或 _ 或 他们用于标准私人的任何东西 成员变量。

卢克，

我为我的类库对象使用 _ 前缀。出于我所说的原因，我专门为 UI 使用匈牙利符号。

【参考方案8】：

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

【参考方案9】：

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

我不喜欢下划线，因为它看起来有点难看，但我不得不承认它有一个优势（或劣势，取决于你的观点）：在调试器中，所有私有变量都将位于顶部，因为_ 位于字母表的顶部。但话又说回来，我更喜欢我的私有/公共对在一起，因为这样可以更轻松地调试 getter/setter 逻辑，因为您可以看到私有和公共属性彼此相邻，

【参考方案10】：

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

【参考方案11】：

我将 m_ 用于成员变量，但我越来越倾向于只使用 lowerCamelCase，就像我对方法参数和局部变量所做的那样。公开的东西在 UpperCamelCase 中。

这似乎在 .NET 社区中或多或少被接受。