76. Lotus Notes编程中的命名习惯

程序里实体的命名规则和习惯

在一种开发环境里编程，会用到各种实体（开发中用到的从文件类型、程序的组织单元到数据库对象的种种对象，不用对象一词以与面向对象语言里的对象区分）。实体种类的多少，与所用语言和平台的复杂程度和特点有关。例如用像JavaScript的脚本语言就只会遇到对象、函数、变量等寥寥几种实体；使用Java时就会用到接口、类等更多实体；如果用到了数据库，又会涉及到诸如数据库、表和字段等相关的实体；而使用Visual Basic 6和Lotus Notes这样的开发平台时，还需要理解种种文件类型或设计元素的用途。所有这些实体在创建时都需要命名（除了匿名对象这样的特例），和给人取名字一样，给这些抽象的实体命名也有某些规则和习惯。首先名字要符合实体所在系统限定的规则，比如能使用哪些字符，长度不超过多少。在符合这些限制的巨大可能性以内，通常还有一些约定俗成或最佳实践的惯例。前者是历史上形成，沿用下来的习惯，了解并遵循它们可以更容易读他人的代码，同时使自己的代码更容易被他人读。常量大写，变量小写，就属于这类习惯。后者是经过实践证明的有益的命名方式，使得代码更清晰、容易理解，减少混乱和无意的错误。比如.Net中接口都以大写字母I起首，以与类的名称区分，这样不仅一目了然，而且使得一个接口和实现这个接口的默认类都能采用简单的名称，如ICollection和Collection。

Lotus Notes编程中的命名习惯

在Lotus Notes编程中，要命名的实体有这么几类。一是其中的各种程序语言内的实体，像LotusScript和Java里的类、方法和变量等，它们的命名习惯与在一般的编程语言中无异。二是各种设计元素的命名。其中又可以细分出是相当于关系型数据库里对象命名的视图、表单和字段的命名。本文主要讲的就是后面这一类，依据的是笔者长年的经验和实践。

中文OR英文

首先要说的是名称用的字符。对以西文为母语的人，这不是问题，用字母和数字的命名是很自然的选择。但对中国人来说，特别是英文不好的，就会有干脆用中文命名的想法。很多关系型数据库都限制其中实体的命名须用字母数字（alphanumeric）加上其他一些字符如下划线_，Lotus Notes偏偏在这方面很宽松，无论是设计元素还是字段的名称，都允许使用多字节编码的汉字。因此笔者真的见过不少Lotus Notes应用程序里表单、视图甚至字段的名字都是中文。但是就像在某些关系型数据库的命名规范里建议的那样，以ASCII以内的字符命名具有最好的跨平台兼容性和性能，在Lotus Notes里也最好遵循这个原则。不过对中国人来说，用字母命名还有一种可能，就是拼音。很多人就采用拼音首字母的形式命名字段，如报关日期就用bgrq。这种方法的缺点也是很明显的，那就是常常让别人看得一头雾水，即使是命名的程序员，以后维护代码的时候也会弄不清楚这样一个字段名的含义。命名最大的原则就是清晰，或者说直观，也就是从名称能容易地理解被命名者的含义，其次是简洁。汉字不是表音文字，一音对多字，就算用整体的拼音也不能清晰地表意。所以命名最好还是用英文。哪怕不知道去查词典也是值得的，顺便还学习了英文。

名称和别名

我们知道一个设计元素可以有名称和多个别名。在程序中引用时可以使用其中任何一个。通常我们可以用描述性的一个或多个词语作一个设计元素的名称，以简洁的同时表明它的类型和含义的一个词语作它的别名，如以Exchange Rate作名称，fmExchangeRate作别名。这样我们在Designer里设计元素列表的第一列看到的名称能让我们清楚地了解某个元素的用途，第二列里显示的别名则用以在程序里引用。

类型前缀

编程中对各种不同类型的文件和对象，命名时常常冠以指示类型的前缀。例如在用户界面开发时，有表单叫做frmMain，文本框叫做txtTitle。在Lotus Notes里，给设计元素起名字时采用这样的规则也是有益的。这种原始的“命名空间”使得几个相关的不同类型的设计元素可以用相同的名称又不致混淆，比如记录和显示汇率的表单和视图分别以fmExchangeRate和vwExchangeRate命名，在代码中引用时就十分清晰。另外一个好处就是传统的Lotus Domino的web开发会用到各种设计元素的URL，它们在数据库名称后没有分类，直接以名称定位，这时有类型前缀的名称就含意清楚，而且不会出现不同类设计元素重名的问题。

类型前缀使用表示类型的单词的简写（abbreviation）。严格地说，英文里的简写包括三类：一类是狭义的简写，保留单词起首的几个字母，略去余下的部分，如radio简写作rad。一类是缩写（contraction），省去构成单词的某些个音节或者从每个音节提取其始或结尾的字母，通常为辅音字母，如button缩写成btn。还有一类则是首字母缩写词（acronym），也就是取多个单词的首字母组成一个新词，如ASCII就是American Standard Code for Information Interchange的缩写词。在类型前缀里会用到前两类。虽然笔者也总结出大致的规则，例如什么时候用第一类，什么时候用第二类，缩写时除去元音字母保留辅音字母，但如果觉得麻烦可以直接参看国外代码的范例，毕竟类型缩写数量有限。

设计元素

类型前缀可用三字母也可用两字母，因为Lotus Notes的设计元素种类不多，用两字母也不会出现重复，笔者就一直使用如下的类型前缀：

表单：fm

视图：vw/vh

页面：pg

代理：ag

帧结构集：fs

视图根据用途可分为两种，一种是作为用户界面可见的，另一种则仅仅是程序里会用到，例如用来查询的。用vw（view）和vh（view hidden）两种前缀区分命名对理解和维护代码都有益处。脚本库的前缀会在下面专门说明，其他诸如共享字段和视图列不会单独用到，导航器和各种资源文件也不会在代码里引用，还有其他很少用到或数量很少的设计元素，加上类型前缀的意义就不大。

脚本库

在Lotus Notes客户端应用程序开发中，基本只会用到LotusScript的脚本库（Java的使用范围很狭窄，Java脚本库很罕见），此时它们的名字只要代表包含的功能就可以，例如Commons、Log4Dom、SimpleFlow。进行经典的web开发时，会多出JavaScript脚本库，但是因为JavaScript和LotusScript分别承担前端和后端的功能，命名上也不易出现冲突。到了XPages开发的时代，新增加了服务器端JavaScript脚本库，一个多用途的应用程序或者模版很可能包含几种语言的脚本库，彼此有用同一个名称的可能。但是Designer将它们视为同一类型的设计元素，不允许重名。另外因为Designer中脚本库列表默认是按名称排序的，即使点击类型列标题按类型排序，重新打开列表时又会恢复按名称排序，这样即使Designer允许不同语言的脚本库重名，在列表里也会出现各种语言的库混杂显示。所以有必要在命名时附上前缀将不同语言的库区分开来。笔者曾经想以模仿路径的形式命名：js\Utility、ssjs\Utility，这样看上去很直观，XPage也能引用，唯一问题是SSJS里允许用import指令引用另一个SSJS文件，这里的脚本库名称正反斜线都不允许。最后还是以下面的简单前缀形式命名：

LotusScript：ls

JavaScript：js

Server Side JavaScript：ssjs

例如：

字段

最后说说字段的命名，前面已经提到了最好用表示涵义的英文单词。需要多个单词时采用任何一种骆驼拼写法（CamelCase）都可以，如CurrentOwner或currentOwner。有些公司和程序员在所有的字段名称前都加上F_，如F_Address，笔者认为这样既无必要又增添了输入和查看字段时的麻烦，本来在一个文档的属性信息框的字段标签页里可以看到按拼写排序的所有字段，还可以输入首字母快速定位，加上F_后就须用肉眼挨个查找。

还有些人会像程序中命名变量一样给字段的名称加上类型前缀，如txtBook、numPrice、dateBirthday。这样做不能说没有提示意义，但是加大了字段名的长度，并且也有上面同样的查找上的问题。不加前缀的理由还有一点就是Lotus Notes平台不适用于开发包含大量数字计算的系统，数据库内的字段大部分保存的是文本，少部分数字和日期类型的字段也能从名称本身获得一些提示，例如名为Price、Count、Sum的字段就很可能包含数字，而名字含有date、time的字段就应该是日期类型的。