在使用C#之前,C++是我的主要编程语言。而匈牙利命名法深深地印在我的心中。
我在没有阅读C#书籍或其他语言指南的情况下完成了一些小项目。在这些小的C#项目中,我使用了类似于
private string m_strExePath;
直到我在 Stack Overflow 上看到一篇文章说:
不要使用匈牙利命名法。
那么为什么?难道我是唯一一个在我的 C# 代码中使用 m_strExePath 或 m_iNumber 的人吗?
在使用C#之前,C++是我的主要编程语言。而匈牙利命名法深深地印在我的心中。
我在没有阅读C#书籍或其他语言指南的情况下完成了一些小项目。在这些小的C#项目中,我使用了类似于
private string m_strExePath;
直到我在 Stack Overflow 上看到一篇文章说:
不要使用匈牙利命名法。
那么为什么?难道我是唯一一个在我的 C# 代码中使用 m_strExePath 或 m_iNumber 的人吗?
lblTitle = Label
txtTitle = TextBox
ddlTitle = DropDownList
虽然不是唯一的人,但我觉得使用匈牙利命名法还是相对较少。个人来说,我不喜欢简单地重复声明中已经存在的类型信息的匈牙利命名法。(“真正”的匈牙利命名法的粉丝会解释其中的区别-它从来没有让我太烦恼,但我可以理解他们的观点。如果你为长度和重量等单位使用常见前缀,即使两者都是整数,也不会意外地将一个长度变量赋值为重量值。)
然而,对于私有成员,你可以随意做你想要的事情-与你的团队达成一致的命名约定即可。重要的是,如果你希望你的 API 与 .NET 的其余部分相适应,则不要在公共成员(包括参数)中使用匈牙利命名法。
不,你并不是唯一一个这样做的人。只是普遍认为在C#中使用匈牙利命名法并不是最好的命名方式(因为IDE已经解决了很多匈牙利命名法试图解决的问题)。
m_strExePath
或m_iNumber
的人吗?exePath
不是一个字符串,那么它会是什么?作为你代码的读者,我为什么需要知道它是一个字符串?知道它是可执行文件的路径不就足够了吗?`m_iNumber`只是命名不当。这是什么数字?它是干什么用的?你已经告诉我两次它是一个数字,但我仍然不知道数字的含义。exePath
是FileInfo
类型,那它命名不当,那就是你的问题所在。变量的名称表明它是一个路径,而不是一个实际文件。因此,当我使用它时,我希望它的行为像一个路径名,而不是一个文件。 - jalf你肯定不是唯一一个这样的人,但我希望你是下降趋势中的一部分 :)
匈牙利命名法的问题在于它试图通过命名约定实现一种类型系统。这是极其有问题的,因为它是一种仅包含人工验证的类型系统。项目中的每个人都必须同意相同的标准,进行严格的代码审查,并确保所有新类型都被分配了适当和正确的前缀。简而言之,在足够大的代码库中无法保证一致性。如果没有一致性,那么你为什么要这样做呢?
此外,工具不支持匈牙利命名法。这似乎是一个愚蠢的评论,但请考虑重构。在匈牙利命名约定系统中,每次重构都必须伴随着大规模的重命名以确保前缀得以维护。大规模的重命名容易受到各种微妙错误的影响。
与其使用名称来实现类型系统,不如仅依赖于类型系统。它具有自动验证和工具支持。新的IDE使发现变量类型(智能感知、悬停提示等)更加容易,真正消除了对匈牙利命名法的最初需求。
如果你使用的是VS IDE而不是文本编辑器,匈牙利命名法很少有价值,它会降低可读性而不是提高可读性。
我目前只看到两个领域在使用匈牙利命名法:
_someVar
)btn
表示Button,lbl
表示Label等)成员变量前面的下划线似乎会在未来一段时间内继续存在,但我预计匈牙利命名法在控件名称上的流行度将会减弱。
this._something = something
,而不是this.something = something
;如果没有一些区分字段和参数的方法,我曾经输入过something = something
,导致该字段被初始化为零,这很难在后来发现。请注意,在某些地方,.NET参考源仍然使用m_MemberVariable
作为私有变量,并且MSDN不再指定私有字段的命名约定。 - jrhMyProperty
而不是myProperty
将会导致StackOverflowException
;如果你在打字时按错了 tab 键,智能感知会高兴地自动完成到MyProperty
,但如果你用字段作为前缀,则不那么容易。另见:Jeff Atwood 的文章。 - jrh