1 代码开发规范
1.1 字符集规范
统一采用UTF-8，包括jsp、java文件。
1.2 注释规范
1.2.1 类注释
每个类注释都会被置于注释定界符/**...*/中，注释换行时用<br> 而不是用<p></p>，一个注释对应一个类或接口。该注释应位于声明之前，示例：
/**
* ClassName: 类名称<br>
* Description: 类描述<br>
*
* @author 作者<br>
* @date 日期
*/
注意：注释换行时用<br> 而不是用<p></p>，一个注释对应一个类或接口。该注释应位于声明之前
1.2.2 方法注释
方法注释，需要说明该方法的作用，声明参数类型、返回类型，声明所要抛出的异常，实例：
/**
* @MethodName: 方法名称<br>
* @Description: 方法描述<br>
* @param 参数说明<br>
* @return 方法返回值说明<br>
* @throws ServiceException 异常抛出说明
*/
1.2.3 变量注释
变量注释，采用单行注释符：//
1.2.4 业务代码注释
注意点：（1）关键业务要有注释
（2）算法要有注释
1.3 格式化排版
1.3.1 排版
代码格式统一按Eclipse默认的格式化排版，在代码上传svn前，一定要用Eclipse中的Ctrl＋shift＋f格式化一遍代码，
同时做optimize imports的操作，在Eclipse中的快捷键为Ctrl＋shift＋o。
1.3.2 缩进
使用Tab键进行缩进
不同层级的代码必须使用换行和缩进，以便看清代码结构
1.3.3 换行
类、方法、变量声明后须换行
“{” 跟在声明后，无须换行
分号后须换行
If判断中，即使只有一行代码，也需要跟{}，进行换行
1.3.4 空格
在操作符之间应该有空格，示例：
If(areaId != null) 合规
If(areaId!=null) 不合规
1.4 命名规范
1.4.1 命名方法
规范如下
|
对象
|
命名规则
|
示例
|
说明
|
|
包
|
com.公司名.层级.模块名
|
com.ctid.business.intercept.service.impl
|
全部小写
|
|
类
|
帕斯卡(Pascal)命名法
|
DateUtil
|
简拼大写
|
|
方法
|
骆驼(Camel)命名法
|
getJFSCDataSource
|
简拼大写
|
|
接口
|
帕斯卡(Pascal)命名法
|
ICalloutService
|
以I作为前缀、 简拼大写
|
|
变量
|
骆驼(Camel)命名法
|
defaultDataSource
|
简拼大写
|
|
常量
|
全部大写，采用下划线_分离
|
SYS_USER
|
变量名尽可能描述变量含义
|
|
JSP文件
|
骆驼(Camel)命名法
|
login.jsp,userAdd.jsp,userEdit.jsp |
简拼大写
|
1.4.2 规则描述
规则1：所有单词的第一个字母大写，其它字母小写，如：AreaCode
规则2：第一个单词的第一个字母小写，其它单词的第一字母大写，如：areaCode（变量，方法）
规则3：如果某一串字母名称为几个单词的首字母拼接，则全部使用大写，如CRM
规则4：接口名、类名的后缀，以所在包路径的，最后一级路径命名，但是大小写有一定规律：
util包下的类，后缀以Util结尾，如：StringUtil
如果某个类为接口或抽象类的执行类，则需要在所执行的接口或是所继承的类名后加Impl表示该类为执行类，
同时去掉所执行的接口或是所继承的类名字的首字母I，如：接口为IArea，则它的执行类为AreaImpl
规则5：接口名、类名、方法名不能有下划线 "_”
1.4.3 变量命名
变量的命名遵循规则2
变量名简单贴切
避免单个字母的缩写
每行只声明一个变量
1.4.4 常量命名
常量定义为static final，常量的声明，所有字母大写，单词之间采用下划线分开,
例如：public static final int SERVER_PORT = 8080;
系统常量，放在系统常量文件里
VO常量，比如表状态，单独放在vo文件里
1.4.5 方法命名
遵循规则2
建议使用动词或动词短语（动词、动词+名词或形容词）的形式
对于存取器（accsseor）方法， 即获取成员函数和设置成员函数命名为getXxx()和setXxx()；布尔型的获取成员函数命名为isXxx()或hasXxx()。
例如：
getFirstName() setFirstName() isNumeric() hasNext()
accsseor方法需使用eclipse自动生成。
1.5 控制语句规范
1.5.1 If语句规范
单条if语句需要用{ }包括。
1.5.2 Switch使用规范
case分支用{ }包括。
避免switch穿透，要加break
switch添加default语句，可预防以后增加另一个选项后没有中断执行导致错误的情况出现。
1.6 字符串使用规范
一个字符串多次使用，需要创建一个字符串常量
字符串判空方法使用，调用公共组件
1.7 文件资源操作规范
对文件、IO流打开与关闭成对出现。调用close( )方法。
1.8 代码行数规范
一个类不要超过1000行代码
1.9 方法创建规范
一个方法只有一处return，并在方法尾部
方法功能单一，复杂度不超过10
1.10 SQL编码规范
单表查询用hql。
SQL中需使用变量绑定。
尽可能减少对表的查询次数。
多表查询时，选择记录少的表(或者交叉表)作为基础表，放在from子句的最后面。
多表查询时，过滤掉最大记录数的条件放在where子句的最后面。
2 异常处理开发规范
每个类与每个方法都需要try catch。
用户交互类需求，异常接收后要返回友好的提示。
系统采用统一的异常类进行所有异常的封装
|
异常类
|
名称
|
示例
|
说明
|
|
ServiceException
|
应用级异常
|
try {
….
} catch (Exception e) {
Log.error("错误描述！"+e.getMessage());
throw new ServiceException ("错误编码", "错误描述！"+e.getMessage(),e);
}
|
对try…catch中捕获的系统异常，使用ServiceException封装，封装后的异常能保留并取到原始的异常信息。
|
注意：日常开发过程中，还需对异常处理注意如下一些约束：
1)ServiceException异常的描述信息应简明扼要，且完整准确的描述相关异常信息。
2)运行时异常的判读处理，如空指针NullPointerException、数组越界等。
3)异常捕获后，要进行必要的处理，切忌捕获异常而不做任何处理，导致业务逻辑缺失。
3 日志输出开发规范
3.1 输出日志要求
日志必须用log4j输出。
示例：
private static final Log logger = LogFactory.getLog(DataInterceptServiceImpl.class);
系统中避免出于调试目的的System.out.println()语句，另外日志中尽量输出有意义的信息。
不要直接用e.printStackTrace()输出异常信息。
3.2 日志级别与内容控制
做日志输出时，要注意区分级别，当前系统采用3种日志级别：
Debug：只是调试看的信息，用debug级别，比如对象内容，sql语句等。
Info：对于系统级的输出用info级别
Error：对于错误信息要求用error级别
4 公共组件使用规范
系统提供公共组件，涉及到公共组件相同功能的业务对象时，应严格使用公共组件，而不允许单独编写代码实现，以保证公共组件的统一性、一致性和可维护性。
公共组件包括：
1、字符串处理
2、日期处理
3、其他工具类
5 框架使用规范
5.1 struts命名空间使用规范
@Namespace禁止使用。
禁止使用servlet。
Action必须继承BaseAction。
5.2 Hibernate使用规范
单表操作必须使用hql。
参数操作需要绑定变量。
5.3 公共配置修改需要组内审核
struts.xml等配置文件修改需要审核
6 开发行为要求
写需求文档，流程文档，数据库文档，组内审核通过后，才能进行开发。
升级前提交代码列表与数据库脚本，要保证数据库脚本运行没有错误。
代码提交：每天根据情况提交自己编译通过的代码，经过本地测试，才能提交。提交前，先更新代码，禁止覆盖别人提交的代码。
版本管理：所有文档提交svn，修改后及时提交。
知识积累：过程中有任何心得、疑问、思路或创新，部门内部进行集中讨论解决，形成我们的知识库，记录在本开发规范的备忘中。
周五下午2点周例会，总结工作。
关键需求点，进行邮件确认。
