呼叫中心项目软件开发代码规范性标准.docx

呼叫中心项目软件开发代码规范性标准.docx

《呼叫中心项目软件开发代码规范性标准.docx》由会员分享，可在线阅读，更多相关《呼叫中心项目软件开发代码规范性标准.docx（8页珍藏版）》请在冰点文库上搜索。

呼叫中心项目软件开发代码规范性标准

文档标号：

方正国际软件有限公司

呼叫中心项目软件开发

代码规范性标准

文档标号

版本

1.0

作者

IT系统集成事业部

发布日期

施行日期

2011-8-1

数据分类

内部

修订历史

版本号

修订描述

施行日期

版权所有：

©2010-2013方正国际软件有限公司

编辑软件：

MicrosoftOffice2007中文版

方正国际软件有限公司呼叫中心项目软件开发代码规范性标准

（2011年08月01日方正国际软件有限公司主管副总裁审批通过，自2011年08月01日起施行）

文档管理信息表

主题：

代码规范性检查标准细则

版本：

V2.0

内容：

开发人员使用，管理人员检查的依据

关键字

规范

参考文档：

编写时间：

2010-5-27

编写人：

陈兵

文档修改记录表

修改人

修改时间

修改内容

陈兵

2010-5-27

创建

陈兵

2010-7-15

修订

程国艮

2010-7-22

修订

1概述

1.1目的

●制定规范，约束开发人员在开发过程中随意性、不规范性，减少开发后期带来的不必要的成本浪费。

1.2要求

●开发人员开发之前，必须通读开发规范中的内容（理解规范中的要求）。

●在开发过程中，必须严格执行规范中制定的规范内容，如果检查过程中发现没有按规范执行的，按《呼叫中心项目软件开发代码规范性检查办法》执行。

2规范细则详述

2.1注释

所有的注释文字一律使用简体中文。

2.1.1类注释

1）在import语句和class声明语句之间必须加类的注释，格式如下：

要有功能说明、创建人、创建日期、修改人（如果修改了部分代码）、修改日期、修改说明、版本号。

如下：

-----------------------------------------------------------------------------------------

/**

     *@功能                      UI--用户登录

     *@author 创建人         Xxx

   *@date 创建日期     2007-03-03

     *@author 修改人          xxxx

     *@date 修改日期     2008-02-12

     *@author 修改说明  调整登录

     *@version1.0

   */

-----------------------------------------------------------------------------------------

修改说明这里可以只是做个简单的说明，具体情况可以看代码中的修改记录。

2.1.2方法注释

1）在方法前必须添加注释，格式如下：

-----------------------------------------------------------------------------------------

/**

*功能说明

*@创建人

*@时间

*@参数说明

*@参数返回说明

*/

-----------------------------------------------------------------------------------------

2）对于设置（Set方法）与获取（Get方法）成员的方法，在成员变量已有说明的情况下，可以不加注释。

3）对于类似stuts的ACTION方法，其输入输出参数固定、格式统一的，参数说明可以省略。

2.1.3属性注释

1）注释格式：

//注释内容。

写明该属性的含义。

2.1.4代码内注释

1）主要变量定义、引用及复杂的算法需注释。

2）代码段落注释，说明以下代码段在该方法中具体实现的功能；

3）注释格式：

//注释内容或以“/*”开始，“*/”结尾注释。

2.1.5修改注释

当创建人与修改人不是同一个的情况下，需加修改注释。

1）在增加的代码前添加注释，内容包括增加部分功能说明、增加人、增加日期、增加部分开始声明。

2）结束部分添加注释，注释内容包括增加部分功能说明、增加人、增加日期、增加部分结束声明。

3）以上包括增加、修改和删除的注释。

2.2命名

2.2.1包命名

1）包的名字应该能够说明包的用途，通常应是名词或名词短语。

包的名字应该全部由小写字母构成.；

2）如果包的用途必须由两个或多个单词才能描述清楚，可以直接将这些单词连接作为包名.”；

3）如果连接后的包名太长，可以使用单词的缩写（缩写必须不会引起歧义）或取每个单词的首字母。

2.2.2类命名

1）首字母大写；

2）类的名字应该能够说明类的用途，通常应是名词或名词短语。

类的名字由若干单词连接而成，每个单词的首字母应大写，其他字母小写；

3）如果某个词是一个缩写形式，则这个词应全部大写.。

2.2.3方法命名

1）所有的方法（构造函数除外）名都应能说明方法的用途，通常取动词或动词短语，也可能是名词或名词短语。

方法名由若干单词连接而成，第一个单词应全部小写，其余单词的首字母大写。

2）对于以名词或名词短语命名的方法，建议改成动词或动词短语形式。

2.2.4变量命名

1）通常由1—3个英文单词/简写组成，尽量不能超过4个单词；

2）通常组成形式是：

形容词+名词，名词+名词，动词+名词；如：

nUserNum，AddUser.jsp

3）每个变量首字母必须小写，每个单词首字母大写（数据库除外）；

4）可以添加数字或下划线的组合；

5）避免使用类似的名字如变量名persistentObject与persistentObjects不能同用；

6）绝对禁止包含汉字、拼音、无含义字母、空格和特殊字符；

2.2.5常量命名

1）变量的名字应该都大写，并且指出完整含义。

2.2.6JSP命名

4）Jsp的文件的开头都以小写开头，其他单词第一字母要大写，其余小写。

5）同一个业务建立一个意义相同单词的目录，且相同的jsp都在相同的目录下。

2.2.7SSH命名

2.2.7.1Package的命名及应用

包的最上层规定为com.order.cc

1）在每次增加一个业务功能时，就要增加一个新包，新包下的结构包括：

action、form、entity、dao、idao、svc。

2）action：

jsp提交时对应的方法入口。

3）form：

jsp与后台数据的缓冲。

4）entity：

相关数据对象的实体文件。

5）dao：

所有的数据库操作都要在此类中完成，禁止数据库sql在其他类中出现。

6）idao：

dao的接口类。

7）svc：

业务逻辑在此类中实现，与dao挂钩。

注：

此包在命名可以根据具体的功能来灵活命名，一般业务可以参照此包的结构来实现

2.2.7.2Class的命名及应用

1）Class的名字必须由大写字母开头并且每个独立的单词第一个字母也必须以大写开头，其他字母都小写的单词组成。

2）Action类名形式：

描述性名称+Action.java

3）Form类名形式：

描述性名称+Form.java

4）Entity类名形式：

描述性名称+Entity.java

5）Dao类类名形式：

描述性名称+DAO.java

6）IDao类类名形式：

I+描述性名称+DAO.java

7）svc类类名形式：

描述性名称+Serivce.java

注：

此类的命名是对上面包命名的一个规定，如包不属于上述结构，class完全可以不依照上面的命名

在struts-config.xml命名path时，不要带路径，防止路径混乱。

正确的命名如下：

path="/menuAction"

2.3格式

2.3.1缩进规范

1）类中的成分，使用缩进；

2）方法体或语句块中的成分，使用缩进；

3）换行时的非起始行，使用缩进；

4）缩减量一般为在上一级成分的基础上再缩进四个空格。

2.3.2空行规范

1）包语句与import语句间空两行；

2）Import语句与class定义之间空两行；

3）方法与方法之间以空行分隔；

4）函数内部数据与代码之间应空至少一行，代码中适当处应以空行空开，建议在代码中出现变量声明时，在其前空一行；

5）在方法内部代码的逻辑段落小节之间，建议使用空行。

2.3.3类行数

1）每个类需小于1000行；

2.3.4函数行数

1）每个函数行小于70行；

2.3.5单行长度

1）单行长度不超过125个字符；

2.3.6if{}语块行数

1）if语块间不能超过30行；

2）其他while语句等{}类似；