瑞星卡卡安全论坛

begin
RecordCount := RecordCount + 1;
ReadLn ( Score [ Recordcount ] )
end;
{ lines using RecoudCount }
…
    如果循环体长度较长的话，那就很容易使人忘记它代表的是什么，因此最好给循环控制变
量一个富有意义的名字。由于经常进行更改，扩展和拷贝等代码到另一个程序中，因此，大多
数有经验的程序员都避免用i、j、k 这类的名字。
    使循环体变长的一个常见原因是嵌套。因此，对于一个有多重嵌套的循环，最好给循环控
制变量以较长的名字以便改善其可读性：
for TeamIndex := i to TeamCount to begin
for EventIndex := 1 to EventCount[ TeamIndex ] do
Score[ TeamIndex, EventIndex ] := 0
end;
    通过精心对循环控制变量进行命名，可以避免它们的交叉：当你想用i 时误用了j，或者
想用j 时却又误用了i。这样做也可以使对数组的存取操作更为明了。Score [ TeamIndex,
EvenIndex ]显然要Score[i,j]更能说明问题。总之，应尽量避免使用 i、j、k 来命名。如果不得
不使用它们的话，那除了把它们用作循环控制变量之外，最好不再用作别的变量名。这一约定
是众所周知的，如果不遵守它只会引起别人的困惑。
9.2.2  状态变量命名
    状态变量描述的是程序所处的状态。下面论述了它们的命名原则。
    用比flag 更好的名称来命名变量，最好不用flag 作为状态变量的名字。之所以要避免使用
flag 作为标志名称，是因为它不能告诉你关于这个标志的任何信息。为了清楚起见，应该给标
志赋值，并且用枚举类型、命名常量或当作命名常量使用的全局变量对其进行测试。下面是一
个在C 语言中不恰当命名标志的例子。
if（ Flag ）...
if（ StatusFlag & 0x0F ）...
if（ PrintFlag ＝＝ 16 ）...
if（ ComputerFlag ＝＝ 0 ）...
 
Flag = 0x1;
StatusFlag = 0x80;
PrintFlag = 16；
ComputerFlag = 0；
    如果这个程序不是你写的，而且也没有注释告诉你的话，你是无法知道类似statusFlag =
0x80 之类的语句到底是要干什么的,而且你也无法知道Statusflag和0x80 到底是什么意思。以

下是功能与内容相同但清楚得多的程序：
if ( DataReady )...
if ( CharacterType ＆ PRINTABLE_CHAR )...
if ( ReportType ＝＝ AnnualRpt )...
if ( RecalcNeeded ＝＝ TRUE )...
DataReady = TRUE；
CharacterType = CONTROL_CHARACTER;
ReportType = AnnualRpt;
RecalcNeeded = FALSE;
    显然，第二个例子中CharacterType = CONTROL_CHARACTER 的意义要比第一个中
StatusFlag = 0x80 的意义要清楚得多。同样，第二个例子中的条件语句if ( ReportType ＝＝
AnnualRpt ) 也显然要比第一个中的if ( PrintFlag ＝＝ 16 )清楚得多。第二个例子表明，你可借
助预先命名的常量或枚举类型来使用这种方法。以下是如何利用枚举类型和命名常量来设置上
例中用到的值，仍用C 来实现：
/* values for DataReady and RecalcNeeded */
#define TRUE 1
#define FALSE 0
/* values for CharacterType */
#define LETTER 0x01
#define DIGIT 0x02
#define PUNCTUATION 0x04
#define LINE_DRAW 0x08
#define PRINTABLE_CHAR ( LETTER | DIGIT | PUNCTUATION | LINE_DRAW )

#define CONTROL_CHARACTER 0x80

/* values for ReportType */

Typedef enum { DailyRpt，MonthlyRpt,，QuarterlyRpt，
AnnualRpt，AllRpts｝REPORT_TYPE_T;
    当你发现自己“侦破”了一段代码时，应该考虑对变量重新命名。侦破一桩凶杀案是可以
的，但你不应该去“侦破”一段代码。代码应该是具有良好可读性的。
9.2.3  临时变量命名
    临时变量用来保存中间运算结果，如用作暂时保留某个位置或保留内务操作值。通常把它
们叫做TEMP 或X 等没有什么意义的名字。临时变量的使用往往标志着程序员还没有完全理解

程序。而且，由于名义上给了它一个“临时”的状态，因而程序员们在处理它们时往往会采取
漫不经心的态度，从而增大了出错机会。
    要警惕“临时”变量。通常，暂时保留某些值是完全必要的。但如果在你的程序中出现很
多临时变量的话，则说明你对它们在程序中作用和使用它们的目的还不清楚。先让我们看一下
下面用C 语言写成一个例子：
/* Compute root of a quadratic equation．
This assumes that ( b^2 - 4 * a * c ) is positive. */

Temp = sqrt ( b^ 2 - 4 * a * c );
root[0] = ( -b + Temp )/( 2 * a );
root[1] = ( -b – Temp )/( 2 * a );
    把由公式sqrt ( b^2 - 4 * a * c ) 计算出来的值储存起来是个不错的想法，尤其是在后面还有
两处用到了它的情况下。但是用TEMP作为它的名称不能告诉你关于这个变量意义的任何信息。
一个较好的作法是下面这个例子：
/* Compute roots of a quadratic equation.
This assumes that ( b^2 – 4 * a * c )is positive */

Discriminant = sqrt ( b^2 - 4 * a *c );
root[0] = ( -b + Discriminant )/( 2 * a );
root[1] = ( -b - Discriminant )/( 2 * a );
    事实上两段代码是完全一样的，但是通过采用更准确也更能说明问题的变量名，大大改善
了其可读性。
9.2.4  逻辑变量命名
    以下命名逻辑变量的几条准则：
    记住一些典型的逻辑变量名。以下是些非常有用的逻辑变量名：
    Done。用Done 来表示某项工作已经完成了。这个变量可以表示子程序或循环是否已经完
成。当某项工作没有完成时，把Done 的值赋为False；当某项工作已经完成时，把Done 的值
赋为True。
    Error。用Error 来表示发生了错误。当没有错误时将Error 的值赋为False；当有错误时将
其
赋为True。
    Found。用Found 来表示是否找取了某个值。当搜寻数组来查找某一值或搜寻某一文件表
查找某一雇员的识别卡时，没有找到某一值时将其值赋为False，而一旦找到这个值。则把Found
值赋为True。
    Success。用Success来表示某一操作是否已成功地完成。当某一程序无法完成时，将Success
的值置为False；而当某一操作已经完成时，将Success的值置为True。如果可能的话，可以用
比Success 更准确更具有表达力的名称来代替它，用这个新名称应可以精确地表达出到底是什
么已 成功地完成了。比如当某一程序完成处理后就可以认为是成功时，就可以用
Processingcomplete 来代替Success。如果当找到某一值就可以为程序是成功的时，可以用Found
来代替它。

用旧含非真即假的名字来给逻辑变量命名。像Done或Success等之所以是恰当地逻辑变量
名，是因为它们的状态是非真(True) 即假 (False)的。某项工作或者完成了或者没完成；或者
是成功的或者不成功，不会有第三种状态。而类似Status 或SourceFile 等则是不恰当的名字，
因为看不出它们的状态是非真即假的。如果Status 的值是True，那它是否意味着某种物质有状
态呢？任何物质都有状态。或者说当其值是True 时，意味着某种物质的状态很好，而为False
时则意味着状态不好？仅从Status这个名称是无法回答这些问题的。
    为清楚起见，最好用Error 或Status_OK 等来代替Status；用SourceFileAvailable 或
SourceFileFound来代替Source。
    有些程序员喜欢用Is 用为逻辑变量名的前缀，于是变量名就成了一个问句：IsDone？
IsError？IsSuccess？当用True 或False 来回答上述问题时，就等于给变量赋了值。这样做的好
处是可以避免那些不恰当的名称。如IsStatus显然没有任何意义。
    使用肯定的逻辑变量名。否定式的变量名如NotFound、NotDone和Notsuccessful 等在“非”
运算中是很难读懂的，如：
if not NotFound
    这类名字应该用Found，Done，Successful等来代替，以方便“非”运算。
9.2.5  枚举类型命名
    当使用枚举型变量时，可以通过使用相同的前缀或后缀表示某一类型的元素都是属于同一
组的，如下面的这段Ada 程序所示：
type COLOR is ( COLOR_RED, COLOR_GREEN，COLOR_BLUE );
type PLANET is ( PLANET_ERATH, PLANET_MARS, PLANET_VENUS );
9.2.6  常量命名
    对常量来说，应该用它所代表的抽象实体而不是数值来命名。FIVE 是一个很不恰当的常量
名称（不管它代表的数值是否是5.0）；CYCLES_NEEDED 则是个恰当的名称，
CYCLES_NEEDED 可以等于5.0也可以等于6.0，而Five = 6.0则是个荒唐的语句。由于同样的
原因，BAKERS_DOZEN 也是很不恰当的变量名，而MAX＿DONUTS 则要恰当得多。
9.3  命名约定
    有些程序员往往坚持标准和约定，这是有其原因的。然而，某些原则和约定过于刻板而且
往往是无效的，这只会破坏你的创造力和程序的质量，这实在是个不幸，因为有效的标准和约
定是你的工具箱中最为有效的工具之一。这一节将讨论为什么及什么时候和怎样建立你自己的
命名标准。
9.3.1 为什么要建立约定
约定可以带来如下好处：
·  它们可以使更多的东西成为独立的。通过做出一个总体决定而不是许多局部决定，你

可以把精力放到更重要的程序特性上。
·  它们可以帮助借鉴其它项目的经验并移植自己的经验。相似的名字可以使你更容易并且更
自信地猜测陌生变量的功用。
·  它们可以使你更快地熟悉新项目的代码。与一套连贯的而不是各式各样、东拼西凑的    代
码打交道显然要容易得多。
·  防止一变量多名。如果没有命名约定，你很可能给一个变量取两个或更多的名字。例如，
你可以把所有点的个数称作PointTl又称作Ttl_Points。这对于你来说可能没什么，因为
你是程序的作者。但对以后要读这个程序的程序员来说，这很可能会使人困惑。
·  弥补语言的缺陷。你可以利用命名约定来仿效命名常量或枚举类型，这一约定可以区分局
部、模块和全局变量，也可以并入编译程序所不支持类型的信息。
·  命名约定还可以强化相关项之间的联系。如果你使用的是结构化数据，那么编译程序会自
动考虑到这一点；如果所用的语言并不支持结构化数据，可以通过命名约定来补充它。像
AddrmPhone 和Name 等名称并不表示变量是相联系的。但如果你决定所有的雇员数据变量
名都要用EmP 作为前缀，那么毫无疑问，EmpAddr、EmpPhme 和EmpName就是联系的变量了。
通过建立伪结构化数据，弥补语言的缺陷。
    关键是有约定总比没有约定好，哪怕约定是随意的也罢，约定的效力并不是由某一确定的
约定，而是由约定存在决定的，它可以增加代码的结构并减少你的担心。
9.3.2  什么时候使用命名约定
    关于这个问题并没有一成不变的答案。但在以下几种情况下，使用命名约定我认为还是值
得的。
·  当同时有几个程序员从事一个项目时。
·  计划把程序交给另一个程序员进行修改和维护时（这时命名约定是必不可少的）。
·  当你的程序将由其它程序员来评审时。
·  当程序规模过大，需要按部分来考虑它时。
·  当一个项目中要频繁使用某些不常见的词汇，而又想开始编码时。
命名约定总是有益的，上述准则可以帮助你确定在某一项目中命名约定使用的广泛程度。
9.3.3  正式程度
    不同约定的正式程度是不同的。一个简单的约定可能只有一句话，“使用有意义的名称”。
略微正式的约定将在下节讨论。更正式些的约定将9.5 节中论述。一般来说，约定正式程度是
由从事一个程序的程序员人数、程序的规模和程序的预测生存期决定的，在小型程序中，严格
的约定往往是不必要的。如果是需要几个人协作（可能是在开始，也可能是在程序生存期内的
某个时间）的程序，那么可读性往往要依赖正式的命名约定来保证。
9.4  非正式命名约定
绝大多数项目都采用如下所述的非正式命名约定。

9.4.1    与语言无关的约定准则
    以下是一些与语言无关的约定准则：
    标识全局变量。常见的编程问题之一是误用全局变量。可以在所有的全局变量前面都加     
上g_作为前缀来解决。比如看到g_Running Total时，程序员就会知道这是一个全局变量，从而
把它作为全局变量对待。
    标识模块变量。模块变量是在模块内部供几个子程序使用的变量。要能清楚地表明它既不
是全局变量也不是局部变量。这可以用在变量前加m_作为前缀来解决。在C 中，你可以通过在
任何子程序外说明Static 变量来建立模块层次的数据。这样的变量对文件中子程序来说都是可
用的，但文件外的子程序则无法使用。
    标识类型定义。类型的命名约定需要有两个功能：它们要明确地指出某一名称是类型名称，
同时要可以避免类型名称与变量名称相冲突。为了达到这两个要求，使用前缀或后缀不失为一
个好办法。在 Pascal 中，可以使用小写的_t 来表示类型名称，例如 Color_t 或 Menu_t。在C
中用这种办法稍有些困难，常见的办法是用大写字母组合如COLOR或MENU来表示类型名，但这
可能与命名预处理程序常量相混淆。而“_t”这一约定已经被标准类型size_t 所采用了,因此可
以用“_T"表示类型名称，如COLOR_T 和MENU_T。
    标识命名常量。需要对命名常量加以标识，以便可以使你知道是在用一个变量（其值可能
变动）还是在用一个命名常量给某个变量赋值。在Pascal或C 中，你还可能是在用函数给某一
变量赋值。这些语言，并不要求函数使用括号。而在C中，即使是不带参数的函数也必须使用
括号。
    给命名常量命名的一种办法是“_C”作为其名称的后缀。在Pascal中，用这种方法可以产
生出像MaxRecs_C或MaxlinesPerPage_ C之类的名字。在C 中，你可以用“_C”作为其后缀。
    标识枚举类型。与命名常量同样的原因，枚举类型也需要被标识出来。即将其与变量、命
名常量和函数加以区别。常用的方式是用“_e”或“_E”作为后缀。
    标识输入参数。有时输入参数会被错误改动。在像C 或Pascal这样的语言中，当一个被改
变过的值返回调用子程序时，必须予以明确地说明。在C 中，这是用“*”说明的，在Pascal
中用的是VAR，Ada语言中使用的是out限定词。在其它语言如Fortran 中，如果你改变了一个
输入值，那么不管你是否愿意，它都将被返回，但假如你建立了命名约定，在约定中规定只用
于输入的参数前面要采用IP 作为前缀，那么当发现在等号左边出现了带有IP 前缀的变量时，
你就可以知道发生了错误。比如在程序中看到IPMAX = IPMAX＋l语句，就可以立刻认定它是
错误的，因为前缀IP 表明IPMAX 的值是不允许变动的。
    对名字作格式化以增强可读性。增强可读性常见的两项技术是用分隔字符或大写字母将单
词分隔开来。例如，GymnasticsPointTotal 或Gymnastic_Point_Total 的可读性显然是要强于
GYMNASTICSPOINTTOTAL。C、PASCAL、Ada 和其它语言都允许大小写混用的方式。C、
Pascal和其它语言都允许使用的下划线“_”作为分隔符。
    尽量不要混合使用这两项技术，那样会降低可读性。如果坚持采用其中任何一种,那么你的
代码的可读性将大为改观，关于变量名第一个字母是否应该大写的问题，激烈的争论已经持续
了很长时间（是TotalPoints 好还是totalPoints好？）。但是只要保持一致性，我认为二者区
别实际上并不大。

9.4.2    与语言有关的命名约定
  应当遵守所使用语言的标准命名约定。
你可以发现许多书中都讲述了语言的形式准则。关于C、Pascal 和Fortran 的准则将在下
面予以论述。
C 约定
有些命名的约定是只适用于C的，可以在C中使用这些约定，也可以改变它以使其适应其
它语言。
·  c 和ch 是字符变量
·  i 和j 整型下标
·  n 是数量
·  p 是指针
·  s 是字符串
·  预处理程序宏指令是以全部大写来表示的，这通常扩展到包含typedef
·  变量和子程序名称都是小写的
·  下划线“_”用做分隔符
这些是在UNIX 操作系统下用C 语言编程的一些通用约定。在不同的环境下，这些约定是
有区别的。在Microsoft Windows环境下，C程序员们往往愿意使用匈牙利命名约定，并且对变
量名称是大小写混用的。在Macintosh 环境下，C 程序员们往往乐于使用类Pascal 的命名约定
给子程序命名。因为Macintosh工具箱和操作系统子程序都是为Pascal接口设计的。
Pascal 约定
Pascal 中只有几条特殊的约定，你可以在Pascal 中使用它们，也可以改进它们以适应其它
语言需要。
·  i、j和k 是整型下标
·  变量和子程序名称是以大小写混用的形式出现的
Fortran 约定
Fortran 有一些语言本身固有的命名约定，在Fortran 中可以使用它们。但我想如果不把它们
扩展到其它语言的话，全世界都会因此而感激你的。
·  以字母I到N 开头的变量名是整型的
·  I、J 和K只能作为循环控制变量
·  X、Y 和 Z是浮点数
9.4 .3  命名约定举例
    当命名约定准则长达几页时，它们看起来是非常复杂的。事实上，命名约定是完全不必要
复杂到可怕程度的，你可以改进它们以适应你的需要。变量名应包括三个方面的信息：
·  变量内容（它代表的是什么）

·  变量数据类型（整型、浮点等）
·  变量在程序结构中的位置——例如，定义变量的模块名称或者一个表示变量是全局的
前缀。
以下是C和Pascal中采用前面讲过的命名原则进行命名的一些例子。我并不是想把这些约
定推荐给你，而是想给你一些变量名应包括哪些信息的想法。
Pascal 命名约定示例

约定类别      约定内容
LocalVariable  局部变量名是大小写混用的。这个名称应与潜在的数据类型无关，且应
指出这个变量代表的到底是什么
RoutineName()    子程序也是大小混用的（具体讨论见5.2 节）
m_ModuleVariable  仅供某一模块子程序使用的变量以m_作为前缀
g_GlobalVariable    全局变是用g_为前缀                     
Constant_C      命名常量以_C 作为后缀
Type_t        类型以_t作为后缀
Base_EnumeratedType 枚举类型是以其基本类型的助记符作为前缀的，如Color_Red,
Color_Blue

C 命名约定示例

约定类别        约定内容
GlobalRoutineName()    公用程序名称是大小写混合使用的
_FileRoutineName()    供某一个模块专用的子程序以下划线作为前缀
LocalVariable  局部变量名是大小写混用的。其名称应与数据类型无关且应指明变
量代表的究竟是什么                             
_FileStaticVariable  模块（文件）变量以一个下划线作前缀
GLOBAL_GlobalVariable  全局变量是以定义它的模块（文件）名称的全大写形式助记符作为
前缀的，如SCR_Dimension
LOCAL_CONSTANT    仅供某一子程序或模块 (文件) 专用的命名常量是全大写的
GLOBAL_CONSTATNT  全局命名常量名字是全大写的，且以它的模块（文件）名称           
助记符的大写形式来作前缀的，如SCR_MAXROWS
TYPE          类型定义是全大写的
LOCAL_MACRO()    仅供某一子程序或模块（文件）专用的宏定义是大写的
GLOBAL_MACRO()  全局宏定义是大写的且以它的模块（文件）名称助记符大写形式为
前缀
9.5  匈牙利命名约定
    匈牙利命名约定是一整套对子程序和变量进行命名的详细约定。这一约定广泛应用在C 语
言中，特别是在Microsoft Windows环境下用C编程时，之所以称其为“匈牙利”是因为遵循这
一      约定的命名看起来像是外文。而且其发明者Charles Simonyi原来是匈牙利人。
匈牙利命名主要包括三个部分：基本类型、一个或更多的前缀、一个限定词。在下面的例
子是在C中采用匈牙利命名约定写成的，你很容易就可以对其加以改进以扩展到其它语言中。

9.5.1 基本类型
    基本类型是指待命名变量的数据类型。基本类型名称通常不指向程序语言中任何一种已定
义的标准数据类型。基本类型是一种更抽象的数据类型，基本类型名称指向的可能是窗口、屏
幕区和字体等实体。在匈牙利名称中只能使用一种基本类型。
基本类型是用你为某一特定程序建立的简写代码来表示的，然后对其作标准化以便在这一
程序中继续使用。以下是在一个文字处理程序中你可能用到的基本类型：
      基本类型            含义
wn            窗口
    scr            屏幕区
fon            字体
ch  字符（不是C意义上的字符，而是这个文字处理程序
将用来在文件中代表字符数据结构意义上的）
pa              段落
使用匈牙利基本类型时，同时也定义了与基本类型使用同样缩写的数据类型。因此，如果
使用了如上表列出的基本类型，就会看到像这样的数据说明：
WN wnMain;
SCR scrUserWorkspace;
CH chCursorPosition;
9.5.2  前缀
    前缀放在基本类型前面并描述了变量的使用。与基本类型不同的是前缀在某种程度上是标
准化的。表9-1 中示出了一级标准匈牙利前缀：
表9-1  匈牙利变量名称前缀
      前缀              含义
a                数组
c                数目（如记录、字符等等的个数等）
e                数组的元素
g              全局变量
h              处理
i                数组下标
m              模块层次上的变量
p（lp,np）          指针（长指针、近指针——对于Intel 机器）
前缀是小写的，并且放在变量名中基本类型的前面。如果需要的话，可以把它与基本类型
或与其自身组合使用。例如，一个表示窗口的数组，可以用“a”来表示它是个数组，用“wn”
表示窗口，因此可以用“awn”来作这个数组的名称；而对窗口的操作可称为hwn；cwn是窗口
的数目；cfon是字体的种类等等。
9.5.3  限定记号
    匈牙利名称的最后一个要素是限定词。限定调是名称的描述部分。没有使用匈牙利约定

时也可利用这部分来补偿。在上前面给出的例子——wnMain、scrUserWorkspace 和
chCursorPosition 中，Main、UserWorkspace和CursorPosition 都是限定词。在本章前面给出的关
于变量命名的准则也适用于限定词。
除了自己生成的限定词以外，匈牙利约定中还对容易在处理时产生混淆的概念给出了标准
化限定词。在表9-2 中，表示了些标准限定词。
                            表9-2  匈牙利约定中的标准限定词
限定词          含义
Min      数组或其它表中绝对的第一个元素
First  数组中需要进行处理的第一个元素。First含义与Min 相近，但First是相
对操作的第一个，而Min 则是指数组本身的第一个元素
Last      在一个数组中需要最后进行处理的元素。Last是First的反义词
Lim  在一个数组中需要处理的元素上界。与Last一样，Lim也是First的反义
词，但与Last 不同的是,Lim 代表的是数组的不完全上界；而Last 代表
的则是最后一个元素。通常，Lim等于Last 加1                                 
Max  Max 指的是数组或表列中的绝对最后一个元素而不是相对操作的最后一
个元素
限定词能够而且应该与基本类型和前缀联合使用。例如，PaReformat 指的是要重新格式化
的段落；apaRefotmat 指的是要重新格式化的段落数组。而ipaReformat 则指的是需要重新格式
化的段落的数量。一个for循环来重新格式化段落的C 程序如下:
for (
theReformat = paFirstReformat;
ipaReformat <= paLastReformat;
ipaReformat++;
)…
可以用PaLimReformat 来代替上例中的变量名PaLastReformat 重写相同的循环，这时，由
于Lim和Last的区别，在确定循环是否结束的检查中，将用“<”来代替“<=”。即用：
ipaReformat < PaLimReformat
来代替
ipaReformat <= PaLastReformat

9.5.4    匈牙利名称举例
    以下是利用匈牙利约定产生的变量名。其中变量名的基本类型部分采用的是前面文字处理
程序示例中的基本类型。
变量名        意义
ch  字符变量（并不是C 语言意义上字符，而是指文字处理程序中用来
在文件中代替字符的数据结构）
achDelete      要删去的一个字符数组
ich          字符数组的下标
ichMin        字符数组中绝对第一个元素的下标

ichFirst      字符数组中第一个需要进行某种操作的元素的下标
echDelete      字符数组中产生的某一元素，如ecbDelete = acbDelete   
        [icbFirst]的结果
    pachInsert      要插入字符数组中的指针
    ppach        指向某一字符数组指针的指针
    cchInser      要插入字符的数量
    cscrMenu      用作菜单屏幕区的数量
    hscrMenu      对用作菜单屏幕区的操作
    mhserUserInput    用户输入屏幕区的模块层次上的操作（所有在这一模块中的子程序
            都可对这一变量进行存取操作）
    ghscrMessages    为获得信息而对屏幕区进行的全局操作

    注：上表中某些变量名不含限定词。虽然省略限定词是很常见的，但我们并不提倡这样做，
应尽可能使用限定同。
9.5.5  匈牙利约定优点
    匈牙利约定与其它命名约定一样，拥有由命名约定所带来的一切共同优点。由于有这样多
的标准名称，因此在任何一个单个子程序或程序中要特殊记忆的名字是非常少的。匈牙利约定
完全可以在不同项目中采用。
    匈牙利约定可以使得在命名中容易产生定义的区域变得准确清楚。特别是约定中对First，
Min，Last，Max和Lim的准确区分在实际中是尤其有帮助的。匈牙利约定可以使人对编译程序
无法检查的抽象数据类型进行检查：cpaReformat很可能是错误的，因为cpaReformat 不是数
组，而apaReformat则可能是正确的，因为apaReformat是数组。
匈牙利约定可以在类型不严格的语言或环境中对类型进行说明。例如，在Windows 环境下
编程时，需要你放弃许多类型，这极大地限制了编译程序进行严格类型检查的能力。而建立约
定则可以对环境的这一弱点作出补偿，匈牙利约定还可以使名称更简洁，可以用CMedals 而不
用TotalMedals来代表奖牌的数量，使用pNewScore，而不是用NewScorePtr命名一个新分数指
针。
9.5.6  匈牙利约定缺点
    一些版本的匈牙利约定事实上忽视了用抽象数据类型作为基本类型。它们以程序语言中整
型、长整型、浮点数和字符串为基础来建立基本类型。匈牙利约定基本类型事实上是没有什么
价值的，因为它使得程序员陷入对类型进行人工检查的困扰之中，而不是让编译程序对类型进
行更加快速而又准确的检查。
    这种形式匈牙利约定的另一个问题是它把数据的意义与其表现联系在一起。比如，说明某
一变量是整型的，把它改为长整型的时，不得不改动这一变量的名称。
匈牙利约定的最后一个问题是它鼓励了懒惰、不含什么信息的变量名的出现。当程序员用
hwnd 来命名对窗口的操作时，往往忽视了他所指的到底是哪种窗口、对话框、菜单还是帮助区
的屏幕？显然用hwndmenu 要比hwnd 清楚得多。以变量的意义为代价来获得对其类型的精确
描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义和精确的类型。