一、数据库的命名

表的命名：   tg_ 表功能名词 _info( 主表 )

            tg_ 表功能名词 _ 其他修饰词 ( 副表，扩展表 )

视图的命名： vg_ 表功能名词 _info

序列的命名： seqg_ 表功能名词 _id

存储的命名： pg_ 功能修饰

函数的命名： fg_ 功能修饰

二、包、类和方法的命名

a) 包的命名

一级包名	二级包名	三级包名	四级包名
com	mylink	dao （实现类）	sql （ xml 文件）
modal （对象类）	按照模块命名
service （服务类）	按照模块命名
action （行为类）	按照模块命名
interface （接口类）	按照模块命名
tools （工具类）	按照模块命名
back （废弃的类）
com	kingter	util （工具类，无业务关系）

 

表和模块的对应关系会在设计说明书中说明。

b) 类和方法的命名

类的命名参照 java 命名规范中的要求 :

类，接口：由一个或几个单词组成，每个单词的第一个字母大写，比如： StringBuffer

类：一般用名词和名词词组命名 ;  IndexOptimizer.java;     WebDbReader.java

接口：与类相同，可以使用形容词词缀，比如 Runnable, Comparable

方法：除第一个字母小写外，和类，接口的命名规则一样。比如： getPersonInfo()

对于取属性值和设置属性值的方法：不管是否是 Bean ，都要遵循 JavaBean 命名规范： getXXX(), setXXX()

转换对象类型返回不同类型的方法：命名成 toType ，比如： toString(), toArray()

返回视图的方法：命名成 asType() 形式， asList()

返回与调用此方法的对象（ Wrapper Class ）同值的原始类型的方法：命名成 typeValue() 形式，比如 intValue(), floatValue(),parseCharacterEncoding(String);

注：需要遵循，类的用途，通常将用途或功能相近的类放置在一起，命名为类主要解决的问题简单表述。只要其他操作人员在看到该类的时候通过名字大概可以知道该类处理那些问题。

三、 Ext 、 Jsp 和 js 的命名

A 、      EXT 编码：

一、     目录管理

1 、 Ext 支持文件目录： .\widgets\ext-3.1.0 标明目前所使用 EXT 版本

      Ext3.1.0

        ┠ ------extend       扩展 Ext 文件目录

         ┠ ------resources    Ext 资源文件目录（ images 、 css ）

2 、各业务模块 JS 文件目录： .\jscript\g3

      ┠ ------qq           qq JS 文件目录 ( 具体相关业务 )

      ┠ ------bas              应用认证 ( 具体相关业务 )

 

 

二、     命名约定

1 、      业务模块 JS 文件命名，相对应具体表操作以表名 ( 小写字母 ) 作为文件名，如操作用户的 JS 文件为 bas_member.js 。

2 、      所有业务 JS 文件中出现的 re_ 、 ds_ 、 cm_ 、 btn_ 、 grid_ 、 win_ 、 frm_ 、 fun_ 、 panel_ 等均不可重名，其命名需加入表名信息，如 bas_member.js 中命名为： re_member 、 ds_member 、 btn_search_member 、 btn_add_member 等。

3 、      业务 JS 文件中按钮 handler 下函数命名同样需加入表名信息，与按钮命名保持对应。

4    业务 JS 文件中查询条件名称同样不可重复，如 bas_member.js 中按姓名查询写法为：

‘姓名：’ new Ext.form.TextField({id:'member_mcsearch',name:' member_mcsearch ',width:100} 传入 ds 写法为：

grid_member.getStore().baseParams.mcsearch =Ext.getCmp("member_mcsearch").getValue();

四、书写注释

      定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性）。

Java 的语法与 C++ 及为相似，那么，你知道 Java 的注释有几种吗？是两种？ 　　

// 注释一行　　

/* ...... */ 注释若干行

不完全对，除了以上两种之外，还有第三种，文档注释： 　　

/** ...... */ 注释若干行，并写入 javadoc 文档

1.注释要简单明了。
String userName = null; //用户名

2.边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。

3.在必要的地方注释，注释量要适中。注释的内容要清楚、明了，含义准确，防

止注释二义性。保持注释与其描述的代码相邻，即注释的就近原则。

4.对代码的注释应放在其上方相邻位置，不可放在下面。对数据结构的注释应放在

其上方相邻位置，不可放在下面；对结构中的每个域的注释应放在此域的右方；

同一结构中不同域的注释要对齐。


5.变量、常量的注释应放在其上方相邻位置或右方。


6.全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以

及存取时注意事项等的说明。


7.在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生成日

期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文

件关系等）；主要函数或过程清单及本文件历史修改记录等。

Java代码
1./**
2.   * Copy Right Information   : Neusoft IIT
3.   * Project                        : eTrain
4.   * JDK version used           : jdk1.3.1
5.   * Comments                  : config path
6.   * Version                       : 1.01
7.   * Modification history     :2003.5.1
8.   * Sr Date   Modified By   Why & What is modified
9.   * 1. 2003.5.2 Kevin Gao     new
10.   **/
/**
   * Copy Right Information   : Neusoft IIT
   * Project                        : eTrain
   * JDK version used           : jdk1.3.1
   * Comments                  : config path
   * Version                       : 1.01
   * Modification history     :2003.5.1
   * Sr Date   Modified By   Why & What is modified
   * 1. 2003.5.2 Kevin Gao     new
   **/8. 在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描

述；输入、输出及返回值说明；调用关系及被调用关系说明等
Java代码
1./**
2.     * Description :checkout 提款
3.     * @param Hashtable cart info
4.     * @param OrderBean order info
5.     * @return String
6.     */
7.    public String checkout(Hashtable htCart, OrderBean orderBean) throws Exception  
8.    { }
/**
      * Description :checkout 提款
      * @param Hashtable cart info
      * @param OrderBean order info
      * @return String
      */
     public String checkout(Hashtable htCart, OrderBean orderBean) throws Exception
     { }9.javadoc注释标签语法

@author 对类的说明 标明开发该类模块的作者
@version 对类的说明 标明该类模块的版本
@see 对类、属性、方法的说明 参考转向，也就是相关主题
@param 对方法的说明 对方法中某参数的说明
@return 对方法的说明 对方法返回值的说明
@exception 对方法的说明 对方法可能抛出的异常进行说明 

建议在方法中的逻辑处填写必要的注释，说明问题的解决流程。

五、第三方包的管理

在系统中如需引用到第三方包，首先查看《第三方包管理文档》中是否存在记录，如管理文档中没有，需在《第三方包管理文档》中登记后使用。包的版本由记录人管理维护。以避免包冲突的发生。

六、配置文件管理

在系统中存在多种配置文件，主要为两种：

一、系统配置文件：系统参数配置文件、数据库配置文件

二、框架配置文件： struts 配置文件、 spring 配置文件、 ibatis 配置文件等。

在系统配置文件中需对配置参数加以说明注释，框架配置文件中尽量分类、有序，以便他人添加配置。

七、团队关于代码的维护

规范团对中的成员对代码的整体维护，在保证代码编译成功的情况下，在离开公司前提交程序到服务器，上班时先获取最新的程序代码后再开始工作。

a) 帮助文件

为能够团队有效的相互协调工作，会不定期的提供代码或外部工具包的帮助手册，作为技术开发文档，团队成员可以了解系统中已有的功能，方法中已有的可重用的则不重新编码，减少开发量，降低代码的维护难度。

b) 类的维护

类的书写人可以新增，修改，删除该类的方法，其他团队成员在开发中出现的新的功能需求，需要在某个类中添加或修改，需联系该类的书写人维护。这样可以保证代码的准确性。不要随便修改他人代码。

如果类中的方法在系统中已取消使用，则在通知书写人确认后转入 back 包中，以备以后使用。

c) svn

开发中的代码是以服务器上 ( 现在服务器是在内网 ip ： 67) 的为准，不能提交有问题的代码。代码提交要及时，准确。在代码提交后要告知小组开发成员，以便能及时获取最新代码。

八、数据库的维护

在开发中数据库是测试的基础。对在测试过程中产生的测试数据，在测试完毕后须及时删除。

 

我看一份编程规范是否有实际意义时，只查看一个指标，“单个方法可以最多能写多少行程序”。

然也。从这个指标的值可以看出一个公司的编程水平。