出于某种原因，我从来没有看到这样做过。有理由不这样做吗？例如，我喜欢 _blah 作为私有变量，并且至少在 Windows 窗体中，控件默认是私有成员变量，但我不记得曾经见过它们以这种方式命名。在我在成员函数的局部变量中创建/存储控制对象的情况下，有一些视觉区别特别有用。
Luke
问问题
1319 次
11 回答
13
这对某些人来说可能是违反直觉的，但我们对 UI 元素使用了可怕的匈牙利符号。
逻辑很简单：对于任何给定的数据对象，您可能有两个或多个与之关联的控件。例如，您有一个在文本框中指示出生日期的控件，您将拥有：
- 文本框
- 指示文本框用于出生日期的标签
- 允许您选择日期的日历控件
为此，我将 lblBirthDate 用于标签，txtBirthDate 用于文本框，calBirthDate 用于日历控件。
不过，我很想听听其他人是如何做到这一点的。:)
于 2008-08-13T03:45:18.550 回答
4
匈牙利符号与否，我更好奇人们是否在 m_ 或 _ 或任何他们用于标准私有成员变量的前面添加。
于 2008-08-13T03:48:00.603 回答
1
我个人用 _ 为私有对象添加前缀
表单控件总是以类型为前缀，我这样做的唯一原因是智能感知。对于大型表单，只需键入lbl并从列表中选择它就可以更容易地“获取标签值” ^_^ 它还遵循Jon Limjap 所述的逻辑。
尽管这确实再次出现了 Microsoft 的 .NET 编码指南，但请在此处查看它们。
于 2008-08-13T05:05:57.077 回答
1
对我来说，在私有成员前加下划线的命名约定的重大胜利与 Intellisense 相关。由于下划线位于字母表中的任何字母之前，因此当我使用 ctrl-space 来调出 Intellisense 时，我的所有 _privateMembers 都位于顶部。
但是，就命名而言，控件是另一回事。我认为范围是假设的，并且在前面加上几个字母来表示类型（例如txtMyGroovyTextbox）出于同样的原因更有意义；控件在 Intellisense 中按类型分组。
但在工作中，一路都是VB，我们做mPrivateMember。我认为 m 可能代表模块。
于 2008-08-13T06:19:16.850 回答
1
我是通过 VB 来的，并保留了控件的控件类型前缀。我的私人成员使用小写字母 (firstLetterLowercase)，而公共成员使用 Pascal/大写字母 (FirstLetterUppercase)。
如果有太多的标识符/成员/本地人有 90% 的机会记住/猜测它的名字，那么可能需要更多的抽象。
我从不相信存储类型前缀是有用的和/或必要的。然而，我确实养成了遵循我使用的任何代码的风格的强烈习惯。
于 2008-08-13T09:31:26.340 回答
0
我不知道，但我很欣赏你的逻辑。我猜大多数人不这样做的原因是下划线在设计时在“属性”窗口中看起来有点难看。它还会占用额外的水平空间特征，这在这样的停靠窗口中非常重要。
于 2008-08-13T03:26:07.217 回答
0
匈牙利符号与否，我更好奇人们是否在 m_ 或 _ 或任何他们用于标准私有成员变量的前面添加。
卢克，
我为我的类库对象使用 _ 前缀。出于我所说的原因，我专门为 UI 使用匈牙利符号。
于 2008-08-13T03:59:21.190 回答
0
我从不在变量名中使用下划线。我发现除了字母（有时是字母数字）字符之外的任何东西都是多余的，除非语言要求。
于 2008-08-13T07:06:15.587 回答
0
我在大写/小写阵营（“标题”是私有的，“标题”是公共的），混合了 UI 组件（tbTextbox、lblLabel 等）的“匈牙利”符号，我很高兴我们没有团队中的 Visual Case-Insensitive-Basic 开发人员 :-)
我不喜欢下划线，因为它看起来有点难看，但我不得不承认它有一个优势（或劣势，取决于你的观点）：在调试器中，由于 _ 存在，所有私有变量都将位于顶部在字母表的顶部。但话又说回来，我更喜欢我的私有/公共对在一起，因为这样可以更轻松地调试 getter/setter 逻辑，因为您可以看到私有和公共属性彼此相邻，
于 2008-08-13T09:12:24.333 回答
0
我写下它们所代表的数据库列的名称。
于 2009-01-05T05:23:20.210 回答
-3
我将 m_ 用于成员变量，但我越来越倾向于只使用 lowerCamelCase，就像我对方法参数和局部变量所做的那样。公共内容在 UpperCamelCase 中。
这似乎是整个 .NET 社区或多或少接受的约定。
于 2008-08-13T04:00:10.953 回答