在解释语言中使用匈牙利符号前缀有意义吗？

Question

首先，为了避免重复问题，我看了一下下面的帖子。

https://stackoverflow.com/questions/1184717/hungarian-notation
Why shouldn't I use "Hungarian Notation"?
Are variable prefixes (“Hungarian notation”) really necessary anymore?
Do people use the Hungarian Naming Conventions in the real world?

现在，所有这些帖子都与C语言，C++，java强类型语言有关。 我知道编译前类型已知时不需要前缀。
不过，我的问题是：

考虑到在运行前无法看到对象的类型，是否值得在基于解释器的语言中使用前缀？

编辑：如果有人能把这篇文章变成社区维基，请这样做。我对这个职位的声誉（或负面声誉）不感兴趣。

Answer 1

在Python中，匈牙利符号表示类型（“systems Hungarian”）不受欢迎的原因很简单。这是误导。一个变量可能被称为iPhones（电话的整数，可能是：-），但是因为它是Python，没有什么可以阻止你把整数以外的东西放进去！也许你会发现你需要这样做是有原因的。然后所有使用它的代码对试图理解它的人来说都是误导性的，除非您全局更改变量的名称。

这种表示法旨在帮助您跟踪静态类型语言中的变量类型，并且在一段时间内可以说是很有用的。但是现在它已经过时了，即使对于静态类型的语言来说，考虑到ide的可用性，它可以更好地完成这项工作。

Answer 2

这取决于您所指的two versions中的哪一个：

• 如果要使用“real”，原始匈牙利符号AKA Applications匈牙利符号，表示逻辑变量类型resp。它的目的，请随意这样做。

• OTOH，被误解的版本AKA系统匈牙利符号，denotng只是物理变量类型是不受欢迎的，不应该使用。

Answer 3

不过，使用匈牙利语系统（在数据类型前面加上前缀）是没有意义的。您可以使用静态语言或动态语言，但编译器或解释器都会处理类型系统。用变量名注释变量类型只会引起歧义（例如，想象一个名为intSomething的浮点）。

对于应用程序匈牙利语来说，这是完全不同的，即以某种使用模式作为前缀。我认为使用这种表示法是一种好的做法，例如“usValue”表示不安全（即未验证）的值。这提供了一个关于用法的视觉提示，并防止您混合使用具有相同类型但不打算一起使用的变量的不同用法（或当它们打算一起使用时，您至少对正在使用的变量有一个概念，并且它们会在您的代码检查雷达上产生一个闪点）。

我经常在MATLAB中使用这样的东西，例如idxInterest来表示double数组不是原始数据值，而是以某种方式感兴趣的索引（进入另一个数组）。我经常使用selInterest（selfrom select）对逻辑索引执行相同的操作（我同意这可能看起来像匈牙利的边界系统），但在许多情况下，两者都可以在同一上下文中使用。

类似地，对于迭代器：我经常使用多维数组（例如4D），在奇怪的情况下，我在一个维度上运行(par)for，迭代器被称为iFoo，jBar，kBaz。。。而它们的上限通常是nFoo，nBar，nBaz。。。（或numFoo，…）。当执行更复杂的索引操作时，您可以很容易地看到哪个索引属于哪个维度（通过前缀您知道使用了哪个数字维度，通过全名您知道该维度表示什么）。这使代码可读性大大提高。

其次，我经常使用dFoo=1;，dBar=2;。。。表示一组变量的维数。这样，您可以很容易地看到，像meanIncome = mean(income, dBar)这样的东西在Bars上取平均值，而meanIncome = mean(income, 2)不传递相同的信息。由于您还必须设置d变量，因此它还用作变量的文档。

虽然在技术上做一些类似iFoo + jBar或kBaz + dBar的事情是不正确的，但是当这些事情确实发生在代码中时，它确实会提出一些问题，并且它们允许您更加警惕地检查该部分。这就是真正的匈牙利符号。

（*）唯一可能有意义的时刻是，完整的框架/语言要求您使用它。E、 win32 API使用它，所以当你直接与它接口时，你应该使用那些标准来将混乱降到最低。然而，我认为寻找另一个框架/语言可能同样有意义，甚至更有意义。

请注意，这与Perl、一些基本方言等中使用的sigils有所不同。它们也表示类型，但在许多实现中，这是类型定义，因此不可能有或很少有歧义。另一个问题是，使用这种类型声明是否是一种好的做法（我不确定自己在这方面的立场）。