匈牙利命名法的好例子是什么？

Question

这个问题是为了寻找好的匈牙利命名法示例，以便我们可以汇集这些示例。

编辑：我同意类型的匈牙利命名并不是必须的，我希望能够找到更具体的示例，例如Joel在他的文章中提到的增加可读性和可维护性的示例（如我的答案所述）。

- Lance Roberts

---

这个问题是在 Stack Overflow 网站刚刚开始时创建的，它实际上不符合该网站今天允许发布的问题类型。尽管如此，它仍然是一个有用的资源，应该因其历史意义和对网站的吸引力而保留。 - Lance Roberts

Answer 1

要求好的匈牙利命名法示例并不现实，因为每个人对于好示例的理解都不同。我个人认为最好的匈牙利命名法是没有匈牙利命名法。该命名法最初旨在表示变量的预期用途而非其类型，但通常用于类型信息，特别是表单控件（例如，txtFirstName表示某人名字的文本框）。这使得代码在可读性方面难以维护（例如，“prepIn nounTerms prepOf nounReadability”），并且在需要更改类型时难以进行重构（Win32 API中有“lParams”已更改类型）。

您应该考虑完全不使用它。例如：

• strFirstName - 这可以改成 firstName，因为它很明显是用来干什么的，在这种情况下类型不是那么重要，应该是显而易见的。如果不明显，IDE 可以帮助您。
• txtFirstName - 这可以改成 FirstNameTextBox 或 FirstName_TextBox。它读起来更好，你知道它是一个控件而不只是文本。
• CAccount - 在 MFC 中，C 被用于类名，但实际上你并不需要它。 Account 就足够了。大写名称是类型的标准约定（它们只出现在特定的位置，所以它们不会与属性或方法混淆）
• ixArray (index to array) - ix 有点晦涩难懂。试试 arrayIndex。
• usState (unsafe string for State) - 看起来像 "U.S. State"。最好使用 state_UnsafeString 或其他东西。甚至可以将其包装在一个UnsafeString 类中，以至少使其类型安全。

- marxidad

---

我同意我们应该按照预定的用途使用它，这也是我希望人们能够贡献的，至于我的即将推出的应用程序，我希望从一开始就创建一个标准。 - Lance Roberts

这里提出的最后一点是在阅读Joel的原始文章后首先浮现在我脑海中的事情。这是类层次结构的目的之一，使用命名约定来实现这一点并不是最优的选择。 - Nerdfest

值得一提的是，在MSDN上有通用命名约定（http://msdn.microsoft.com/en-us/library/ms229045.aspx）。它们说“不要使用匈牙利标记法”。 - Fernando

你可以提出各种论点，让编码实践的某些好处看起来是多余的。让我们以驼峰命名法为例...为什么需要将变量的开头小写？为什么大写下一个单词？userName = UserName = username，它们都同样容易阅读和理解。在使用编码约定时，一致性至关重要，这是最重要的事情，并且暗示匈牙利标记法更糟糕是忽略了所有编码约定都是有效和有用的，如果一致地遵循的话。 - Mike

如果匈牙利标记符号在使用时始终遵循其原始意图，以显示意图为目的，那么很好。但是愚蠢的一致性是年轻程序员思维中的麻烦精灵。 - Mark Cidade

Answer 2

现在经典的文章，正如其他匈牙利帖子中提到的那样，来自Joel的网站:

http://www.joelonsoftware.com/articles/Wrong.html

（请注意，此处保留了HTML标记）

- Lance Roberts

Answer 3

p

(指针的缩写)。这是我使用的主要前缀。我认为它可以为变量添加很多信息(例如，它是一个指针)，因此应该更加重视。

现在使用IDE可以告诉你数据类型是什么(只需要将鼠标悬停在变量名上几秒钟)，所以匈牙利命名法已经有些过时了。但是，将指针看作数据是不好的，因此您需要确保即使用户在编程时做出了不应该做出的假设，也能明显地说明它是什么。

- gbjbaanb

---

是的，这是我考虑使用匈牙利命名法的唯一时机。 - cheduardo

我同意，虽然我发现在结尾加上“_p”更好。这使得结构体指针的解引用更容易阅读，例如somestruct_p->some_member（而somestruct_p.some_member会显然是错误的（按照Joel文章的意思））。 - hlovdal

我也有类似的问题，而且我得出了相似的结论。这里是我的写作 [2014年秋季]。 - Nick Alexeev

Answer 4

t

污染数据。对于来自不受信任来源的所有数据，都要添加前缀，使该变量成为污染数据。在对任何真正的工作进行之前，应清除所有污染数据。

- Rontologist

Answer 5

使用匈牙利命名法指示类型是没有意义的，因为编译器已经为您完成了这项工作。

匈牙利命名法有用的地方在于区分逻辑上不同的变量类型，但它们具有相同的原始类型。例如，如果您使用int表示坐标，则可以将x坐标前缀为x，y坐标前缀为y，距离前缀为d。因此，您会看到以下代码：

dxHighlight = xStart - xEnd

yHighlight = yLocation + 3

yEnd = yStart + dyHeight

dyCode = dyField * 2

等等。这很有用，因为您可以一眼发现错误：如果您将dy添加到y中，则始终会得到一个y。如果您从两个x中减去一个x，则始终会得到一个dx。如果您将dy乘以一个标量，则始终会得到一个dy。等等。如果您看到以下行：

yTop = dyText + xButton

您立即知道它是错误的，因为将dy和x相加是没有意义的。编译器无法帮您捕获此错误，因为就它而言，您正在将int添加到int中，这是可以接受的。

- hhhhhhh

---

我也这样做，大部分时间使用后缀：startX，endY，vertexZ。 - strager

xEnd = xStart + dyField; // 使区域成为正方形 看起来有些错误，但似乎完全有效。 - FryGuy

@FryGuy：在这种情况下，您必须使用一个更一致的名称的另一个变量（例如dxField = dyField; xEnd = xStart + dxField;）。 - alfred barthand

使用匈牙利命名法来指示类型是没有意义的，因为编译器已经为您完成了这项工作。这假定您在编译时捕获它。我最近发现在处理 JavaScript 和变量类型时偶尔使用匈牙利命名法有一些好处。当我编写汇编语言时，我也发现匈牙利命名法非常有帮助。尽管如此，对于非简单意图来说它们是无用的；知道它是数字还是字符串，或者它是字符串还是指向单个字节的指针是很好的，但是区分不同的 HashMap<string, object> 是无用的。 - Dmytro

我的观点是匈牙利命名法有其优点，但如果 (1) 你的命名法非常清晰易懂且能快速找到参考，那么它就变得无用了；(2) 你的命名法非常简洁，缺乏同义词。匈牙利命名法并不应该唯一区分每种对象类型，而是帮助提示标识符中重要的信息，而无需打开高级编辑器。 - Dmytro

Answer 6

不要使用特定语言的前缀。

我们使用：

n：数字 p：百分比1=100%（例如利率等） c：货币 s：字符串 d：日期 e：枚举 o：对象（Customer oCustomer = new Customer();） ...

我们在所有语言中使用相同的系统：

SQL C C# Javascript VB6 VB.net ...

这是一个救命稻草。

- pkario

---

在支持指针但并不意味着指针的语言中，p作为前缀出现时，感觉有些可怕！ - Greg Beech

我们现在很少（如果有的话）使用指针。在我们的工作中，我们经常看到利率（百分比），而不是指针。 但是，使用跨语言前缀的想法是可行的。具体的前缀并不重要，可以自己选择。 - pkario

我使用的是 enSomething 而不仅仅是 eSomething。 - Guy Cohen

我使用enSomething作为包含枚举的变量。 - pkario

Answer 7

在我真正开始阅读和尝试理解匈牙利标记的原始意图之前，我一直强烈反对它。
在阅读了Joel Spolsky的文章“Wrong”和“Rediscovering Hungarian Notation”之后，我真的改变了我的想法。如果正确使用，我相信它必须是非常强大的。
错误的观点 (Joel Spolsky)
http://www.joelonsoftware.com/articles/Wrong.html
重新发现匈牙利标记
http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html
我认为大多数反对者从未真正尝试过它，并且并不真正理解它。我很想在一个真实的项目中尝试它。

- Jonas Söderström

---

根据链接的文章，rg_opbk[i].close比open_books_list[index].close更清晰。有人在自欺欺人。 - Gerhard

总之，HN可以帮助您发现编译器无法察觉的错误，例如混合使用安全和不安全的数据、行和列坐标、数组索引和数组元素。 - darw

总之，HN可以帮助您发现编译器无法发现的错误，例如混合使用安全和不安全的数据、行和列坐标、数组索引和数组元素。 - undefined

Answer 8

魔鬼的代言人：匈牙利标记法最好的例子就是不要使用它。:D

在现代IDE中，使用匈牙利标记法并没有任何优势，因为它们知道变量的类型。当重新定义变量类型时，添加匈牙利标记会增加工作量，因为名称也必须更改（而且大多数情况下，处理变量时您已经知道其类型）。

您还可能遇到标记排序问题。如果使用p表示指针，a表示地址，那么您是将变量称为apStreet还是paStreet？如果没有一致性，可读性会降低，当您需要记住编写标记的顺序时，必须使用有价值的脑力空间。

- Rontologist

---

我同意你不需要在所有类型中使用它，我希望有像Joel所提供的好例子，这样它可以增加可读性和可用性。 - Lance Roberts

匈牙利命名法不应用于类型。您完全正确。然而，最初的意图是将其用于未指定类型的事物，并且在那里有潜在的用途。 - David Thornley

Answer 9

我发现匈牙利标记在动态语言中有时很有用。我特别是想到了服务器端的Actionscript（实质上就是javascript），但它也可以适用于其他地方。由于根本没有类型信息，匈牙利标记有时可以帮助使事情变得更容易理解。

- Herms

Answer 10

匈牙利命名法（我学过的驼峰命名法）在继承一个软件项目时非常有用。

是的，你可以在IDE中将鼠标悬停在变量上并找出它是什么类，但如果你正在翻阅几千行代码，你不想每次都停下来几秒钟——每一次……

记住——你不是只为你或你的团队编写代码。你还要为那些在未来2-5年里接手并增强代码的人编写代码。

- David

---

如果您不包括前缀的说明，那么它们可能对未来的读者来说太神秘了，因此只有在包含前缀的说明时才有用。 - Mark Cidade

驼峰命名法和匈牙利命名法是不同的东西。驼峰命名法只是将每个单词的首字母大写，像这样：doingThisWithYourNames。而匈牙利命名法则涉及在名称前面添加一些类型标识符。 - Herms

有趣。一开始我以为它们是相同的，因为我们总是使用相同的前缀（str、int、dbl、obj、dat等），而且这出现在两个不同的地方。 - David