匈牙利约定优点
匈牙利约定与其它命名约定一样，拥有由命名约定所带来的一切共同优点。由于有这样
多的标准名称，因此在任何一个单个子程序或程序中要特殊记忆的名字是非常少的。匈牙利
约定完全可以在不同项目中采用。
匈牙利约定可以使得在命名中容易产生定义的区域变得准确清楚。特别是约定中对
First，Min，Last，Max 和 Lim 的准确区分在实际中是尤其有帮助的。匈牙利约定可以使
人对编译程序无法检查的抽象数据类型进行检查：cpaReformat[i]很可能是错误的，因为
cpaReformat 不是数组，而 apaReformat[i]则可能是正确的，因为 apaReformat[i]是数
组。
匈牙利约定可以在类型不严格的语言或环境中对类型进行说明。例如，在 Windows 环
境下编程时，需要你放弃许多类型，这极大地限制了编译程序进行严格类型检查的能力。
而建立约定则可以对环境的这一弱点作出补偿，匈牙利约定还可以使名称更简洁，可以用
CMedals 而不用 TotalMedals 来代表奖牌的数量，使用 pNewScore，而不是用
NewScorePtr 命名一个新分数指针。

匈牙利约定缺点
一些版本的匈牙利约定事实上忽视了用抽象数据类型作为基本类型。它们以程序语言
中整型、长整型、浮点数和字符串为基础来建立基本类型。匈牙利约定基本类型事实上是
没有什么价值的，因为它使得程序员陷入对类型进行人工检查的困扰之中，而不是让编译
程序对类型进行更加快速而又准确的检查。
这种形式匈牙利约定的另一个问题是它把数据的意义与其表现联系在一起。比如，说
明某一变量是整型的，把它改为长整型的时，不得不改动这一变量的名称。
匈牙利约定的最后一个问题是它鼓励了懒惰、不含什么信息的变量名的出现。当程序
员用hwnd 来命名对窗口的操作时，往往忽视了他所指的到底是哪种窗口、对话框、菜单还
是帮助区的屏幕？显然用 hwndmenu 要比 hwnd 清楚得多。以变量的意义为代价来获得对
其类型的精确描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义
和精确的类型。