2.框架开发人员应成为遵守编程规范的典范

严格说来，所有开发人员应遵守组织制定的有效的编程规范，不过，由于框架开发人员所编写的程序、文档往往被事务层开发人员所继承或参照，要求更严格一点并不为过，否则可能会造成更多面积的不规范。

       在使用PB、SQLSERVER开发框架程序时通常应遵循以下规范：

1、  PB库文件命名规范

2、  PB对象命名规范

3、  PB变量命名规范

4、  PB对象事件、函数命名、注释规范

5、  界面设计规范

6、  SQL对象命名规范

7、  SQL变量命名规范

8、  设计文档开发规范

9、  帮助文档开发规范

当然，可能还有其它的在组织内生效的规范，如培训管理规范、配置管理规范、文件控制管理规范等。这些规范最好在项目启动后不久建立，在开发过程中不断完善。

以PB库文件命名规范为例，如果框架非常小，可以考虑使用一个库，如果框架较大，建议按照对象的几大类型来建立库文件，库文件应能较为直观地反映出所属模块及主要存放对象，如以“模块代号+对象类型”来命名。对象类型包括窗口、数据窗口、全局函数、用户对象等。由于框架层已实现很多通用功能，事务层的主要工作就是开发数据窗口对象以及定义程序界面入口的窗口，可以考虑事务层库文件只使用窗口、数据窗口类型。例，框架库文件包括syswin.pbl（存放框架窗口）、sysdw.pbl（存放框架数据窗口）、sysfun.pbl（存放框架全局函数）、sysobj.pbl（存放框架用户对象）等，事务层库文件包括invwin.pbl（存放库存管理模块窗口）、invdw.pbl。（存放库存管理模块数据窗口）。

PB对象命名规范包括独立存储的PB对象和容器上控件的命名规范。容器（比如窗口、TabPage、组合控件）上控件的命名规范可以参考PB推荐（或默认）的规范或PFC推荐的规范。独立存储的PB对象的名称应能较为直观地反映出对象的类型、模块、功能。以下是笔者推荐的在程序框架中经常用的对象前缀。

前缀
对象类型
举例
说明

W
窗口
W_sys_about、w_sys_login
建议在第二节加入模块代号

D
数据窗口
D_sys_user_grid、d_sys_user_form
建议在第二节加入模块代号

Dddw
下拉数据窗口
Dddw_sys_user、dddw_sys_menu
建议在第二节加入模块代号，所有下拉数据窗口采用Grid风格

F
全局函数
F_center、f_parse
建议事务层不创建自己的全局函数，如果确实要创建，在第二节加入模块代号

U
标准可视化控件
U_dw、u_cb
建议程序框架中为所有的标准可视控件建立祖先，禁止事务层使用无继承的控件

N
标准非可视化对象
N_tr、n_datastore
禁止事务层使用无继承的标准非可视化对象

Cst
可视化组合控件
Cst_toolbar_list、cst_printconfig_general
建议事务层不创建自己的可视化组合控件，如果确实要创建，在第二节加入模块代号

Nvo
非可视化对象
Nvo_app、nvo_md5
建议事务层不创建自己的可视化组合控件，如果确实要创建，在第二节加入模块代号

M
菜单
M_list、m_pop
建议创建有限的几个菜单对象，公用而不是继承

Stru
结构
Stru_fieltime、stru_rect
通常在调用WINAPI时使用结构


在对PB的变量命名时建议体现出作用范围（全局、共享、实例、局部、参数）、数据类型（标准、枚举、对象和控件、结构等）、功能。例如以“作用范围+数据类型_+变量名称”定义一个变量。尽量少定义全局变量。

在对PB对象的事件命名时建议体现其功能，推荐使用“ue_+事件名”来命名，事件名可以是一个动词或动词加名词，如ue_sort、ue_sendmail等。推荐使用“of_+函数名”来命名对象函数，函数名可以是一个动词或动词加名词，如of_save、of_setproperty等，几类通用的动作包括：is用于判断、get用于获取值、set用于赋值或设置开关选项，如of_ismodified、of_getobjects、of_setmultiselect等。在群体开发时要强调的是一定要为事件、函数、变量注释，否则阅读起来非常麻烦，通常在事件、函数的开始处应有规范的注释，包括事件（函数）名称、参数名称、参数数据类型、参数含义、返回值类型及含义、事件（函数）功能描述、创建人、简要算法描述等信息，可以要求在任何调用非系统的函数、事件时必须加上注释。适当的空行有助于分隔较长的代码和区分不同的功能段。由于PB脚本不区分大小写，原则上你可以随意使用大写或小写，但笔者建议你全部使用小写（除个别WINAPI或特殊代码段必须区分大小外），笔者对大片的大写字母总是有种陌生感。

在同一个系统的不同作业中应尽可能保持用户界面的一致性，这样可以减少不少的培训工作。可以约定几种典型的界面风格，如列表类窗口、输入类窗口、报表类窗口、查询类窗口、参数输入类窗口等，设置这几类窗口的默认界面风格，并可通过系统配置或读取初始化文件来改变界面风格。对管理信息系统而言，界面要力求简单、操作方便、色彩淡雅。

后台对象的命名同样要遵循一定的规范，尽量做到见名识义。曾经看过以数字、中文、拼音命名对象的方法，看起来就头痛，例如：sh01、sh02、t_yh，你能一下子看出该对象的类型、功能吗？复杂、不容易记的命名方法只能无谓地浪费开发人员宝贵的时间。推荐使用下面的前缀来命名常见的SQL对象。

对象类型
命名方法
举例
说明

表
模块代号_+表名+[_表类型]
Pur_po_master、pur_po_detail、pur_vendor_info
通常后缀为master的表存储事务主数据，后缀为detail的表存储事务明细数据，后缀为info的表存储基础数据（也可不带后缀），后缀为rpt的表存储报表数据。表名一定要体现所属模块。

视图
V_+模块代号_+视图名
V_inv_transaction_detail、v_sys_newmessage
如果是直接建立在基表上的视图，可以直接使用“v_表名”命名

存储过程
Usp_+模块代号_+存储过程名称
Usp_sys_createmailtrigger、

Usp_sys_dropmailtrigger
为了区分是用户创建的存储过程还是系统自带的存储过程，建议不要以“sp”为前缀命名存储过程

函数
Udf_+模块代号_+函数名称
Udf_sys_getchildmenuid、

udf_sys_gettriggerlistbystatus
为了区分是用户创建的函数还是系统自带的函数，建议不要以“fn”为前缀命名函数

触发器
T+触发器类型+表名+[_序号]
Ti_pur_po_master、td_pur_po_master、

Tii_pur_po_master
如果是后触发器，可以使用i表示插入、u表示更新、d表示删除，如果是前触发器，可以再增加i标识，对于一些特殊功能的触发器（如自动跳号、自动邮件），可以添加到触发器类型中，如果同一类型触发器有多个，可以加上序号作为后缀


在命名SQL变量时建议体现数据类型（如以c表示char），如果是存储过程或函数的参数，建议以“a+数据类型+变量名称”表示。在后台开发中经常要获取栏位值，建议在命名变量时直接使用栏位名称，如@vc_user_name或@user_name。

设计文档包含很多种，如概要设计、详细设计、单元测试等文档，推荐使用国家软件开发标准GB8567并适当剪裁。

尽管程序中可能有不少注释，但可虑到源代码的安全性，并非每个开发人员都能获取非本人负责的源代码，还是有非常有必要开发相关的帮助文档。Microsoft、Sybase等开发工具所带的帮助文档可以作为我们制作技术性帮助文档的范例。

以上所列的规范并非软件开发时的全部规范，笔者也只是简单地讲述了一番，并未深入。读者可以参考其他的软件开发相关教程。在制定规范时应着眼于使开发人员操作简单、便于阅读、普遍接受为原则，切忌大而全不适用。

由于开发人员也是普通人，在开发过程中也可能存在偶尔的不遵守规范行为，可以通过日常的代码检查、评审找出并纠正。作为一个负责任的框架开发人员，应认识到自己所编写的程序、文档往往被事务层开发人员所继承或参照，如果你很好地遵守规范，就会带动更多的开发人员遵守规范，这样才有利于标准的有利推行和良好的沟通，如果你不能较好地遵守规范，可能造成更多的开发人员随意发挥、破坏规范，你也将花费更多的不必要时间为事务层开发人员讲解你的代码用途。



作者：康剑民 [e-mail]

写作日期：2009-03-02