用旧含非真即假的名字来给逻辑变量命名。像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 清楚得多。以变量的意义为代价来获得对其类型的精确
描述显然是愚蠢的。不过好在可以用加限定词的办法来同时获得完整的意义和精确的类型。

9.6  短名称
从某种程度上来说，使用短名称的意向是早期语言的遗留物。较老的语言如汇编、Basic和
Fortran 语言把变量名长度限制在七到八个字母之间，从而迫使程序员们不得不使用短名称。在
现代语言如C、Pascal 和Ada 中，事实上可以使用任意长度的名称，因此，此时已没有任何必
要再使用短名称。
如果确实不得不使用短名称的话，要注意某些使用短名称的方法要好于其它的。可以通过
去掉不必要的单词、使用短符号或者使用其它缩写技术来建立恰当的变量短名称。可以使用任
意一种缩写技术。但最好多熟悉几种缩写技术因为没有任何一种方法是万能的。
9.6.1  缩写使用的总体准则
以下是使用缩写的几项准则，其中有某些准则是与其它准则相密的，因此不要试图一次使
用其中所有的技术。
· 使用标准的缩写（常用缩写，如列在字典缩写表中的）。
· 去掉所有的非大写元音字母（如Computer写成Cmptr，Screen写成Scrn，Integer写
成Inter等）。
· 使用每个单词的头一个或头几个字母。
· 截掉每个单词头一至三个字母后面的其余字母。
· 使用变量名中每一个有典型意义的单词，最多可用三个单词。
· 每个单词的第一个和最后一个字母。
· 去掉无用的后缀——ing，ed等等。
· 保留每个音节中最易引起注意的发音。
· 反复交替地使用上述技术，直到变量名长度缩短至8 到20 个字母为止，或者到你所
用语言规定的长度为止。
9.6.2  语音缩写
有些人喜欢根据单词的发音而不是拼写来进行缩写。如把skating 写成sk8ting，brightlight
写成bilite，before 写成b4等等。这更像是在让人们破译密码，因此我不主张采用这种方法，但
作为一种技术，你可以尝试一下“破译”出如下语音缩写的含义：
ILV2SK8 XMEQWK S2DTM8O NXTCd TRMN8R
9.6.3  关于缩写的建议
进行缩写时很容易陷入误区。以下是避免出现这种情况的几条准则：
不要通过拿掉单词中一个字母进行缩写。多敲一个字母费不了多少精力，而由此损失的可
读性却往往是巨大的。如把June写成“Jun”或“July”、“Jul”等都是不值得的。而且如果总是
使用这种只省略一个字母的缩写，很容易使人忘记你是否省略掉了一个字母。因此，或者多省
略几个字母，或者使用全称。
缩写应保持一致性。应坚持使用同一缩写。例如，是使用Num或者No，但不要两者混用。

同样，也不要时而缩写某一名称，又时而不缩写。比如，假设已经用了Num就不要再同时使用
Number了。
使用容易发音的缩写。如应使用xPos 而不是Xpsn，用CurTotal 而不是ntTtl。可以用能否
在电话中让对方明白的方法来检验缩写名称，如果不能的话，最好换一个比较容易说的缩写。
避免会引起错误发音的组合。如为表示B的结束，应使用ENDB 而不要使用BEND。如果
使用了良好的分隔技术，则不必理会这条准则。如B_END，BEnd 或b_end 都不会导致错误发
音。
近义词来避免命名冲突。在使用短名称常碰到的一个问题是命名冲突——对不同的名称使
用了同一缩写。如fired 和fullrevenuedisbursal，假设对缩写的要求是限定在三个字母的话，那
么很可能两者都会被缩写成fri，从而产生冲突。
避免这个问题的方法之一是使用近义词。如可以用dismissed 来代替fired，用complete
revenuedisturb 来代替fullrevenuedistural便可以解决上面的问题。
用注解表来说明短名称。在只允许使用简短名称语言中，可以通过加入一个注解表来对变
量名称的缩写加以说明，可以把注解表作为代码开始的注释块，以下是一个Fortran 中使用注解
表的例子：
C***************************************************************
C Translation Table
C
C Variable Meaning
C -------- -------
C XPOS X-Coordinate Position ( in meters )
C YPOS Y-Coordinate Position ( in meters )
C NDSCMP Needs Computing ( =0 if no computation is needed;
C =1 if computation is needed )
C PTGTTL Point Grand Total
C PTVLMX Point Value Maximum
C PSCRMX Possible Score Maximum
C***************************************************************
多从读程序者而不是写程序者的角度去考虑变量名称。你可以通过隔一段时间再阅读一下
程序的方法来检查一下是否需要费很大精力才能弄清变量的含义。如果是这样的话，应改进命
名技术来解决这一问题。
9.7  要避免的名称
以下是应该避免的几种名称：
避免容易产生误会的名称或缩写。要确认变量名称是清楚的。FALSE 通常是指TRUE的反
义词，如果用它当“Fig and Almond Season”的缩写显然是不合适的。
避免含义相同或相近的名字。如果可以交换两个变量的名称而不致影响程序，那说明这两
个变量都应重新命名。如Input和InVal，RecNum和NumRecs等每两个的意义都很相近，如果