在解释语言中使用匈牙利表示法前缀是否有意义？

Question

首先,我已经看过以下帖子以避免重复的问题.

/sf/ask/82930221/
为什么我不能使用"匈牙利表示法"？
是否真的有必要的前缀("匈牙利表示法")？
人们在现实世界中使用匈牙利命名约定吗？

现在,所有这些帖子都与C#,C++,Java - 强类型语言相关.
我确实理解在编译之前知道类型时不需要前缀.
不过,我的问题是:

考虑到在运行时之前无法看到对象的类型这一事实,是否值得在基于解释器的语言中使用前缀？

编辑:如果有人可以将此帖子作为社区维基,请执行.我对这篇文章的声誉(或负面声誉)几乎不感兴趣.

Answer 1

这取决于您引用的两个版本中的哪一个:

• 如果你想使用"真实的"原始匈牙利表示法AKA应用匈牙利表示法,表示逻辑变量类型resp.它的目的,随意这样做.

• OTOH,"误解"版本AKA系统匈牙利表示法,仅仅表示物理变量类型是不受欢迎的,不应该使用.

Answer 2

恕我直言,它永远不会(*)使用匈牙利语系统(前缀数据类型).您可以使用静态语言或动态语言,但编译器或解释器都会使用类型系统.通过变量名称注释变量的类型只会导致歧义(例如想象一个名为float的函数intSomething).

它与Application Hungarian完全不同,即使用某种使用模式作为前缀.我认为使用这种表示法是一种好习惯,例如'usValue'表示不安全(即未经验证)的值.这给出了一个关于用法的视觉提示,并防止你混合使用具有相同类型但不打算一起使用的变量的不同用途(或者当它们打算一起使用时,你至少有一个想法正在使用的是什么,它们会在您的代码检查雷达上产生一些影响).

我经常在MATLAB中使用这样的东西,例如idxInterest,表示双精度数组不是原始数据值,而只是指示以某种方式感兴趣的索引(进入另一个数组).我经常使用selInterest(sel来自select)对逻辑索引做同样的事情(我同意这可能看起来像边界系统匈牙利语),但在许多情况下,两者都可以在相同的上下文中使用.

同样,对于迭代:我经常使用的多维阵列(例如4D),在奇数情况下,我跑(par)for了一个维度中,迭代器称为iFoo,jBar,kBaz,...而他们的上限一般为nFoo,nBar,nBaz,...(或者numFoo, ...).在进行更复杂的索引操作时,您可以轻松地查看哪个索引属于哪个维度(通过前缀,您知道使用的是什么数字维度,您知道该维度代表什么的全名).这使代码更具可读性.

接下来,我经常使用dFoo=1;,, dBar=2;...来表示某组变量的维数.这样一来,你可以很容易地看到,像meanIncome = mean(income, dBar)取平均income比BarS,而meanIncome = mean(income, 2)没有传达同样的信息.由于您还必须设置d变量,因此它还可用作变量的文档.

虽然它不是技术上不正确做这样的事情iFoo + jBar还是kBaz + dBar,它当这些确实发生在你的代码提出了一些问题,他们让你更警惕检查的一部分.这就是真实的(应用程序)匈牙利表示法的全部内容.

(*)它可能有意义的唯一时刻,是您的完整框架/语言要求您使用它的地方.例如,win32 API使用它,因此当您直接与它接口时,您应该使用这些标准将混淆降至最低.但是,我认为,寻找另一种框架/语言可能会有更多甚至更有意义.

请注意,这是一件从不同的印记如Perl中,一些基本的方言等,这些也传达出的类型,但在许多实现,这是类型定义所以没有或很少歧义是可能的.另一个问题是使用那种类型声明是否是一种好的做法(我不确定自己在这方面的立场).

Answer 3

在Python中不赞成使用匈牙利符号传送类型（“系统匈牙利语”）的原因很简单。这是误导。一个变量可能被称为iPhones（手机的整数，也许是:-），但是因为它是Python，所以没有什么可以阻止您将整数以外的东西放进去了！也许您会发现由于某种原因需要这样做。然后，除非您在全局范围内更改了变量的名称，否则所有使用它的代码都会对试图理解它的人产生误导。

此表示法旨在帮助您跟踪静态类型语言中的变量类型，并且可以说是有用的。但是考虑到可以以更好的方式完成这项工作的IDE的使用，即使对于静态类型的语言，它现在也已过时。