Systems Hungarian的吸引力是什么？[关闭]

在什么命名规则，你跟着？，作者说：

另外，我更喜欢使用Charles Simonyi的匈牙利符号进行编码。

我碰到过一些仍然喜欢使用匈牙利语的程序员，大多数都是Petzold / Systems匈牙利语风格的。想想dwLength = strlen(lpszName)。

我已经阅读了使代码看起来错误的代码，并且了解Apps Hungarian的基本原理，其中变量名中包含域类型信息。但是我不理解将编译器类型附加到名称中的价值。

为什么程序员仍然坚持使用这种样式？只是惯性吗？有什么好处可以弥补可读性下降的困扰吗？人们在阅读代码时是否只是学会忽略装饰器，如果是的话，他们如何继续增加价值？

编辑：很多答案都在解释历史，或者为什么它不再相关，在我引用的文章中都涵盖了这两个问题。

我真的很想听听仍然使用它的任何人。为什么使用它？是否符合您的标准？如果不需要，您会使用吗？您会在新项目上使用它吗？您认为优势何在？

目前，出于三种原因，我仍然使用匈牙利语，请明智地避免将其用于其他所有事项：

1. 进行维护时与现有代码库保持一致。
2. 对于控件，例如。“ txtFirstName”。我们经常需要区分（说）“ firstName”值和“ firstName”控件。匈牙利语提供了一种方便的方法。当然，我可以键入“ firstNameTextBox”，但是“ txtFirstName”同样易于理解，而且字符较少。此外，使用匈牙利语意味着易于找到相同类型的控件，并且经常在IDE中按名称将其分组。
3. 当两个变量具有相同的值但类型不同时。例如，“ strValue”表示用户实际键入的值，“ intValue”表示相同的值（一旦解析为整数）。

我当然不希望将自己的想法设置为最佳实践，但是我遵循这些规则，因为经验告诉我，偶尔使用匈牙利利益代码可维护性，却花费很少。就是说，我不断地回顾自己的做法，因此随着我的想法的发展，可能会做一些不同的事情。

更新：

我刚刚读了Eric Lippert的一篇有见地的文章，解释了匈牙利人如何帮助使错误的代码看起来错误。非常值得一读。

我不是使用匈牙利表示法的忠实拥护者，但这样想：

• 我们还可以注意到，在您的代码中查找引用TextBox的字符串更快：通过在搜索框中键入“ txt”。

没想到相反，每个元素都有自己的名称。找到您想去的地方可能会比较慢，对吗？

当我们要引用DropDownList时，对于ddl来说也是如此，它是否更容易？:)

人们不会花太多时间来查找此元素在哪里。

前缀使用不适用于C＃之类的现代语言编译器，但对人类可用（可读）。

当使用1980年代初期的弱类型语言时，Apps匈牙利语（标记表示不能通过类型系统表达的对象的语义属性）是一种处理一些常见错误的合理方法。在当今的强类型语言中，它们几乎没有作用。

匈牙利语系统（用于冗余表示对象的声明类型的标签）从未在任何目的下起作用，只是在代码库上强加了表面统一的外观。它是由非技术经理和经验不足的程序员创建和传播的，他们误解了Apps Hungarian的意图，并认为可以通过复杂的编码准则来提高代码质量。

两种样式都起源于Microsoft。如今，Microsoft的命名约定明确表示“请勿使用匈牙利表示法”。

如果您提出正确的前缀系统，则可能会分散按键的磨损，从而减少替换键盘上的支出。

我想我可以对此进行扩展。我已经在工作场所使用SH了最后一个，哦，大约十年了（因为它在我们的标准中）。它从来没有帮助解决问题。

另一方面，我在“家庭代码”中使用未经修饰但名称明确的变量的时间几乎相等。我从未错过过SH。

在这两个地方，我都编写了要求固定大小的原始类型的协议代码。这是我可以想到的最有益的用例。当我用SH编写时，告诉我什么都无济于事，当我不使用SH编写时，也无碍于我。

因此，总而言之，我能看到的唯一区别是键盘的磨损。

我实际上开始在本月编写的新代码中使用SH。

我的工作涉及用JS重写一些Perl代码，以便可以将其移到我们的Web应用程序的客户端。在Perl中，由于有信号（$ string，@ array，％hash），通常不需要SH。

在JavaScript中，我发现SH对于跟踪数据结构的类型非常有用。例如，

var oRowData = aoTableData[iRow];

这使用整数索引从对象数组中检索对象。遵守该约定为我节省了很多查找数据类型的时间。另外，您可以重载简洁的变量名（oRowvs. iRow）。

tl; dr：当您使用弱类型语言编写复杂代码时，SH可能很棒。但是，如果您的IDE可以跟踪类型，则最好使用它。

我也很好奇看到原理。我们知道他们过去使用它的原因：缺少对类型信息的IDE支持。但现在？简而言之，我认为这是一种传统。C ++代码总是看起来像这样，那么为什么要改变呢？此外，当您在使用匈牙利表示法的先前代码的基础上构建时，突然停止使用匈牙利表示法时，它会显得很奇怪。

Systems Hungarian表示法实际上有点夸大其词，是对“类型”一词的误解。系统开发人员从字面上将其视为编译器类型（字，字节，字符串等），而不是应用程序域类型（行索引，列索引等）。

但我想每个开发人员都要经历几个阶段的风格，这在当时看来是个好主意（而前缀类型对于新手来说似乎是个好主意），然后陷入陷阱（更改类型，创建新的，有意义的前缀，等等）。因此，我想这是一种惯性：来自没有进步的开发人员并意识到为什么它是一个糟糕的选择；来自坚持要求实践的编码标准的开发人员，以及使用的人员<windows.h>。对于Microsoft而言，要更改前缀表示法（在许多地方是不正确的：WPARAM吗？），更改代价将太高。

匈牙利人缺少一件事。匈牙利表示法实际上可以与自动完成一起使用。

假设您有一个变量，名称为intHeightOfMonster。

假设您忘记了变量的名称

可能是heightOfMonster或MonsterHeight或MeasurementMonsterHeight

您希望能够输入字母并为您提供自动完成建议，以获取一些变量名。

知道heightOfMonster是一个整数，您只需输入i和瞧。

省时间。