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

Question

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

Answer 1

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

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

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

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

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

Answer 2

无论是否使用匈牙利表示法，我更好奇人们是否在前面添加 m_ 或 _ 或他们用于标准私有成员变量的任何内容。

Answer 3

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

表单控件始终以类型为前缀 仅有的 我这样做的原因是因为智能感知。对于大型表单，只需键入即可更轻松地“获取标签值” 磅 并从列表中选择它^_^它也遵循 Jon Limjap 阐述的逻辑.

尽管这确实再次符合 Microsoft 的 .NET 编码指南，但请查看它们 这里.

Answer 4

对我来说，在私人成员前面添加下划线的命名约定的巨大胜利与智能感知有关。由于下划线位于字母表中的任何字母之前，因此当我按 ctrl-space 来调出 Intellisense 时，我的所有 _privateMembers 都位于顶部。

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

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

Answer 5

我学习了 VB，并保留了控件的控件类型前缀。我的私人成员使用小驼峰式大小写 (firstLetterLowercase)，而公共成员使用 Pascal/大驼峰式大小写 (FirstLetterUppercase)。

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

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

Answer 6

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

Answer 7

匈牙利的符号是否，我更好奇的是人们是否会预先登记M_或_或他们用于标准私人会员变量的任何东西。

卢克，

我对类库对象使用 _ 前缀。出于我所说的原因，我专门在 UI 中使用匈牙利表示法。

Answer 8

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

Answer 9

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

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

Answer 10

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

Answer 11

我使用 m_ 作为成员变量，但我越来越倾向于使用小驼峰命名，就像我对方法参数和局部变量所做的那样。公共内容采用大驼峰命名法。

这似乎或多或少是 .NET 社区所接受的惯例。