C# 中的匈牙利表示法

Question

在使用 C# 之前，C++ 是我的主要编程语言。 而匈牙利记号则深深地印在我的心里。

我用 C# 做了一些小项目，但没有阅读 C# 书籍或其他关于该语言的指南。 在那些小型的 c# 项目中，我使用了类似的东西，

private string m_strExePath;

直到我读到 SO 中的内容：

不要使用匈牙利表示法。

所以为什么？ 我是唯一在 C# 代码中具有 m_strExePath 或 m_iNumber 的人吗？

Answer 1

Joel Spolsky 有一篇关于这个主题的非常好的文章。 简而言之，实践中使用了两种类型的匈牙利表示法。

第一个是“Systems Hungarian”，您可以在其中使用前缀指定变量类型。 比如字符串的“str”。 这几乎是无用的信息，尤其是现代 IDE 无论如何都会告诉您类型。

第二个是“Apps Hungarian”，您可以在其中使用前缀指定变量的用途。 最常见的例子是使用“m_”来指示成员变量。 如果做得正确的话，这会非常有用。

我的建议是避免像瘟疫一样使用“Systems Hungarian”，但一定要在有意义的地方使用“Apps Hungarian”。 我建议阅读乔尔的文章。 虽然有点啰嗦，但解释得比我好得多。

本文最有趣的部分是，匈牙利表示法的最初发明者 Charles Simonyi 创建了“Apps Hungarian”，但他的论文被严重误解，结果创建了令人厌恶的“Systems Hungarian”。

Answer 2

在进行用户界面设计时，我发现维护匈牙利表示法非常有用。 文本框、标签和下拉列表等项目更容易快速理解，并且经常会出现重复的控件名称：

lblTitle = Label
txtTitle = TextBox
ddlTitle = DropDownList

对我来说，这更容易阅读和解析。 否则，由于 IDE（特别是 Visual Studio）的进步，匈牙利表示法不再适用。

另外，Joel on Software 有一篇与匈牙利表示法相关的优秀文章，标题为：让错误的代码看起来错误 这为匈牙利表示法提供了一些很好的论据。

Answer 3

你不是唯一的人，但我想说这是相对罕见的。 就我个人而言，我不喜欢匈牙利表示法，至少不是简单地重述声明中已经存在的类型信息。 （“真正的”匈牙利表示法的粉丝会解释其中的区别 - 它从来没有让我那么困扰，但我可以理解他们的观点。如果您使用共同的前缀，例如长度单位与重量单位，您就不会意外为长度变量分配一个权重值，即使两者都可能是整数。）

但是，对于私有成员，您几乎可以做您想做的事情 - 与您的团队同意命名约定应该是什么。 重要的一点是，如果您希望 API 与 .NET 的其余部分相适应，请不要在公共成员（包括参数）中使用匈牙利表示法。

Answer 4

不，你不是唯一这样做的人。 人们普遍认为匈牙利表示法不是在 C# 中命名事物的最佳方式（IDE 处理了匈牙利表示法试图解决的很多问题）。

Answer 5

对于任何语言来说，匈牙利表示法都是一个可怕的错误。 您也不应该在 C++ 中使用它。 为变量命名，以便了解它们的用途。 不要将它们命名为 IDE 可以为您提供的重复类型信息，并且这些信息可能会发生变化（并且通常是无关紧要的。如果您知道某个东西是计数器，那么它是 int16、32 还是 int16、32 或 int16 都没有关系） 64. 您知道它充当计数器，因此，在计数器上有效的任何操作都应该有效。它们是坐标。双精度。了解一个值是否以重量、距离或速度为单位可能是相关的，它是否是浮点数并不重要。）。

事实上，匈牙利表示法只是作为一种误解而出现的。 发明者打算用它来描述变量的“概念”类型（是坐标、索引、计数器、窗口吗？），

阅读他的描述的人认为他所说的“类型”是指实际的编程语言类型（int、float、零终止字符串、char 指针）

这从来都不是本意，而且这是一个可怕的想法。 它复制了 IDE 可以更好地提供的信息，但这些信息一开始并不是那么相关，因为它鼓励您在尽可能低的抽象级别进行编程。

那么为什么呢？ 我是唯一一个拥有
我的 C# 中的 m_strExePath 或 m_iNumber
代码？

不，不幸的是没有。 告诉我，如果 exePath 不是字符串，它会是什么？ 为什么我作为代码的读者需要知道它是一个字符串？ 知道它是可执行文件的路径还不够吗？ m_iNumber 只是名字不好。 这是哪个号码？ 它是做什么用的？ 你刚刚告诉我两次这是一个数字，但我仍然不知道这个数字的含义是什么。

Answer 6

你当然不是唯一的人，但我确实希望你是下降趋势的一部分:)

匈牙利表示法的问题在于它试图通过命名约定来实现类型系统。 这是一个非常有问题的问题，因为它是一个仅由人工验证的类型系统。 项目中的每个人都必须同意同一组标准，进行严格的代码审查，并确保为所有新类型分配适当且正确的前缀。 简而言之，不可能保证与足够大的代码库的一致性。 既然没有一致性，你为什么要这样做呢？

此外，工具不支持匈牙利表示法。 从表面上看，这似乎是一个愚蠢的评论，但例如考虑一下重构。 匈牙利命名约定系统中的每次重构都必须伴随大规模重命名，以确保维护前缀。 大规模重命名很容易受到各种细微错误的影响。

不使用名称来实现类型系统，而只需依赖类型系统。 它具有自动验证和工具支持。 较新的 IDE 使发现变量的类型（智能感知、悬停提示等）变得更加容易，并真正消除了对匈牙利表示法的最初渴望。

Answer 7

匈牙利表示法的一个缺点是开发人员在早期编码期间经常更改变量的类型，这需要变量的名称也发生更改。

Answer 8

除非您使用文本编辑器而不是 VS IDE，否则匈牙利表示法没有什么价值，它会阻碍而不是提高可读性

Answer 9

匈牙利表示法的真正价值可以追溯到 C 编程和指针的弱类型本质。 基本上，当时跟踪类型的最简单方法是使用匈牙利语。

在 C# 等语言中，类型系统会告诉您需要了解的所有信息，并且 IDE 以非常用户友好的方式将其呈现给您，因此根本不需要使用匈牙利语。

至于不使用它的充分理由，有很多。 首先，在 C# 以及 C++ 和许多其他语言中，您经常创建自己的类型，那么“MyAccountObject”类型的匈牙利语是什么？ 即使您可以决定使用合理的匈牙利表示法，它仍然会使实际的变量名称稍微难以阅读，因为您必须在开始时跳过“LPZCSTR”（或其他内容）。 更重要的是维护成本，如果您从列表开始并更改为另一种类型的集合（目前我似乎经常这样做）会怎么样？ 然后，您需要重命名所有使用该类型的变量，这一切都没有真正的好处。 如果你一开始就使用了一个像样的名字，你就不必担心这个问题。

在您的示例中，如果您创建或使用一些更有意义的类型来保存路径（例如 Path），那么您需要将 m_strExePath 更改为 m_pathExePath，这是一个疼痛，在这种情况下实际上并没有多大帮助。

Answer 10

我目前看到任何形式的匈牙利表示法的唯一两个区域是：

• 类成员变量，带有前导下划线（例如 _someVar）
• WinForms 和 WebForms 控件名称（btn 表示按钮，lbl 表示标签等）

成员变量上的前导下划线似乎会在我们这里停留一段时间，但我预计匈牙利语在控件名称上的受欢迎程度会减弱。

Answer 11

大多数匈牙利符号描述变量是什么（指针，或指向指针的指针，或指针的内容等），以及它指向的东西是什么（字符串等）。

我发现 C# 中的指针几乎没有什么用处，特别是当没有非托管/pinvoke 调用时。 另外，没有使用 void* 的选项，因此不需要匈牙利语来描述它。

我（以及 C# 领域的大多数其他人）使用的匈牙利语的唯一遗留物是在私有字段前面加上 _，如 _customers 中所示；

Answer 12

匈牙利表示法首次主要用于 BCPL 编程语言。 BCPL 是“Before C 编程语言”的缩写，是一种古老的（1966 年设计的）无类型语言，其中一切都是一个“单词”。 在这种情况下，匈牙利表示法可以帮助进行肉眼类型检查。

从那时起已经过去了许多年......

这是最新的 Linux内核文档说（粗体是我的）：

将函数的类型编码到名称中（所谓的匈牙利语
符号）是大脑受损 - 编译器无论如何都知道类型并且可以
检查这些，这只会让程序员感到困惑。

另请注意，匈牙利表示法有两种类型：

• 系统匈牙利表示法：前缀编码物理数据类型。

• Apps 匈牙利表示法：前缀编码逻辑数据类型。

不再推荐使用系统匈牙利表示法，因为类型检查冗余，而这又是由于编译器功能的进步。 但是，如果编译器不为您检查逻辑数据类型，您仍然可以使用 Apps Hungarian 表示法。 根据经验，匈牙利表示法当且仅当它描述了其他方式无法获得的语义时才是好的。

Answer 13

如果匈牙利表示法深深植根于您、您的团队和您的公司的心中，请务必使用它。 据我从博客和书籍中读到的内容，它不再被认为是最佳实践。

Answer 14

如果你将指针放在 VS 中的变量上，它会告诉你它是什么类型的变量，因此没有理由使用这些神秘的变量名称，特别是因为来自其他语言的人可能需要维护代码和这将成为轻松阅读的障碍。

Answer 15

在像 C# 这样的语言中，以前在 C 和 C++ 等语言中存在的许多变量名称长度限制都不存在，并且 IDE 为确定变量类型提供了出色的支持，因此匈牙利表示法是多余的。

代码应该是不言自明的，因此像 m_szName 这样的名称可以用 this.name 替换。 m_lblName 可以是 nameLabel 等。重要的是保持一致并创建易于阅读和维护的代码 - 这是任何命名约定的目标，因此您应该始终根据此决定使用什么约定。 我认为匈牙利表示法不是最具可读性或最可维护的，因为它可能过于简洁，需要一定程度的前缀含义知识，并且不是语言的一部分，因此难以执行且难以检测当名称不再与基础类型匹配时。

相反，我喜欢通过引用成员的 this 来替换 Apps Hungarian（像 m_ 这样的前缀），引用静态变量的类名，并且不使用局部变量的前缀。 我更喜欢描述变量的用途，例如 nameLabel、nameTextBox、count 和 databaseReference，而不是 System Hungarian（包括变量名称中的变量类型）。

Answer 16

这取决于。

在方法/类中的变量/对象名称中添加数据类型的描述是否足够重要？

系统匈牙利表示法> 应用匈牙利表示法

如果您正在使用具有许多全局变量或/和处理精确数据类型和大小的较低 API 的过程语言（例如 C）进行设计（例如 C 的 其中使用了 40 多种不同的数据类型表示法来描述 int），系统匈牙利表示法更有帮助。

但请注意，许多现代程序员认为在变量名称中添加类型信息是很丰富的，因为许多现代 IDE 都有非常方便的工具（例如 Eclipse 概要，Xcode 的符号导航器，Visual Studio 的 Visual AssistX 等）。 系统匈牙利表示法在早期的编程（例如 FORTRAN、C99）中被广泛使用，当时类型信息作为 IDE 的工具还不容易获得。

系统匈牙利表示法< 应用匈牙利表示法

如果您正在使用更高级别的类或方法（例如，C# 应用程序的用户定义驱动程序类/方法），则表示简单数据类型可能不足以描述变量/对象。 因此，我们在本例中使用 Apps 匈牙利表示法。

例如，如果您的方法的目的是检索可执行路径并在未找到时显示错误消息，则我们不会注意到它是 string 类型，而是会记录更重要的信息来描述变量/对象，以便程序员更好地理解变量/对象的用途：

private string mPathExe;
private string msgNotFound;

Answer 17

我不在乎，我总是使用匈牙利语和帕斯卡/骆驼命名法的组合。

不是针对数据类型，而是针对控件。 因为 txtName 是非常不言自明的。 有些人会将其命名为NameTextBox，这太长了。
lblAge、txtName、rdoTrue、cboCities、lstAccountInfo。 漂亮、快速、紧凑
对于变量，普通变量和属性是帕斯卡大小写。 “firstName = txtFName.Text”（说真的，如果你看不到它并意识到它是一个文本框，sheez）。 然后我将使用驼峰式大小写作为方法

public void PrintNames (string fName, string lName)
{
    lblFullName.Text=fName + " " + lName;
}

所以是的，我使用匈牙利式大小写，所以起诉我。 没有人可以说他们不知道这些变量是什么，我喜欢能够快速查看而不必将鼠标悬停在变量或控件的类型上。 当我第一次开始编程时，我对每个变量都使用了大写，所以这是一个进步。 出于怜悯的缘故，不要将左大括号放在行尾。 漂亮又对称。