首先,为了避免重复问题,我看了以下帖子。
https://stackoverflow.com/questions/1184717/hungarian-notation
为什么不应该';t我使用";匈牙利符号"
变量前缀("匈牙利符号")真的有必要了吗
人们在现实世界中使用匈牙利命名惯例吗?
现在,所有这些帖子都与C#、C++、Java强类型语言有关
我确实理解,当类型在编译之前已知时,就不需要前缀了
然而,我的问题是:
考虑到在运行时之前看不到对象的类型,在基于解释器的语言中使用前缀值得吗
编辑:如果有人能让这篇文章成为社区维基,请这样做。我对这篇文章的声誉(或负面声誉)几乎不感兴趣。
这取决于您所指的两个版本中的哪一个:
-
如果您想使用"真实"的原始匈牙利表示法AKA应用程序匈牙利表示法,表示逻辑变量类型resp。
-
OTOH,"被误解"的版本,AKA系统匈牙利表示法,只表示物理变量类型是不受欢迎的,不应该使用。
IMHO,使用SystemsHungarian(前缀为数据类型)从来没有真正意义。您可以使用静态语言或动态语言,但同时使用编译器或解释器来处理类型系统。通过变量名来注释变量的类型只会引起歧义(例如,想象一个名为intSomething
的浮点)。
它与Application Hungarian完全不同,即在前面加上某种使用模式。我认为使用这种表示法是一种很好的做法,例如"usValue"表示不安全(即未验证)的值。这提供了一个关于用法的视觉提示,并防止您混合使用具有相同类型但不打算一起使用的变量的不同用法(或者当它们打算一起使用时,您至少对正在使用的内容有一个想法,它们会在代码检查雷达上产生一个光点)。
我经常在MATLAB中使用这样一个东西,例如idxInterest
,来指示double的数组不是原始数据值,而是以某种方式感兴趣的索引(进入另一个数组)。我经常使用selInterest
(来自select的sel
)对逻辑索引执行同样的操作(我同意这可能看起来像边界系统匈牙利语),但在许多情况下,两者都可以在同一上下文中使用。
类似于迭代器:我经常使用多维数组(例如4D),在奇数情况下,我在维度上运行(par)for
,迭代器被称为iFoo
、jBar
、kBaz
。。。其上限一般为nFoo
、nBar
、nBaz
。。。(或numFoo
,…)。当进行更复杂的索引操作时,你可以很容易地看到什么索引属于哪个维度(通过前缀你知道使用了什么数字维度,通过全名你知道该维度代表什么)。这使得代码的可读性大大提高。
除此之外,我还经常使用dFoo=1;
、dBar=2;
。。。表示某一组变量的维数。这样,您可以很容易地看到,类似meanIncome = mean(income, dBar)
的东西在Bar
s上取平均值income
,而meanIncome = mean(income, 2)
不传递相同的信息。由于您还必须设置d
变量,因此它也可以作为变量的文档。
虽然从技术上讲,做iFoo + jBar
或kBaz + dBar
这样的事情并不是不正确的,但当这些事情确实出现在代码中时,它确实会引发一些问题,并且它们允许您更加警惕地检查该部分。这就是真正的(应用)匈牙利符号的意义所在。
(*)它可能有意义的唯一时刻是,您的完整框架/语言要求您使用它。例如,win32 API使用它,因此当您直接与之交互时,您应该使用这些标准来将混淆降至最低。然而,我认为,寻找另一种框架/语言可能同样有意义,甚至更有意义。
请注意,这与Perl中使用的sigils、一些BASIC方言等不同。它们也传达类型,但在许多实现中,这是类型定义,因此不可能有歧义或几乎没有歧义。使用这种类型声明是否是一种好的做法是另一个问题(我真的不确定自己在这方面的立场)。
在Python中,匈牙利表示法传输类型("systems Hungarian")不受欢迎的原因很简单。这是误导。一个变量可能被称为iPhones
(电话的整数,可能是:-),但因为它是Python,所以没有什么可以阻止你把整数以外的东西放进去!也许你会发现,出于某种原因,你需要这样做。然后,所有使用它的代码对试图理解它的人来说都是非常误导性的,当然,除非你全局更改变量的名称。
这种表示法旨在帮助您跟踪静态类型语言中的变量类型,可以说在一段时间内非常有用。但现在它已经过时了,即使对于静态类型的语言也是如此,因为IDE可以以更好的方式完成这项工作。
正如人们所提出的,匈牙利表示法是一个合理的想法。应用时?它应该从轨道上被核武器摧毁(这是唯一可以确定的方法。)
匈牙利符号在Java中没有立足之地。Java API不使用它,大多数开发人员也不使用它。Java代码看起来不像使用它的Java。
所有这些对于Python也是如此。