java编码规范.doc

开发过程中，建立JAVA开发规范，统一JAVA代码的编码风格，可以增加清晰性和可阅读性，便于走查和维护！
一 工程编码
建议工程名表意明确
工程项目编码格式使用UTF-8
文件的编码类型统一为UTF-8

二 开发编码规范
2.1 排版规范要求
2.1.1 缩进风格
规则：代码采用缩进风格， tab用4个空格替代。代码中避免使用tab。
说明：用不同的编辑器阅读程序时，因TAB键所设置的空格数目不同而造成程序布局不整齐。在eclipse和myeclipse中可以设置tab转换为空格。
配置方法如下：
（1）点击window -> preferences ->General -> Editors -> Text Editors ，设置如下界面中红色标记内容。

2.1.2 分界符
2.2.2.1 大括号｛｝
规则1：大括号与if, else, for, do, while语句一起使用，即使只有一条语句(或是空)，也应该把大括号写上。
示例：

规则2：左大括号前不换行，左大括号后换行，右大括号前换行
如果右大括号是一个语句、函数体或类的终止，则右大括号后换行; 否则不换行。例如，如果右大括号后面是else， catch或逗号，则不换行。
示例：

一个空的块状结构里什么也不包含，大括号可以简洁地写成{}，不需要换行，如构造函数等

2.2.2.2 空格
规则1：除方法的声明和调用外，小括号前一定要有一个空格。
规则2：分隔任何保留字与紧随其后的左括号( 如if, for catch等。
规则3：分隔任何保留字与其前面的右大括号} 如else, catch。
规则4：在任何左大括号前{ 要有空格
规则5：在任何二元或三元运算符的两侧。这也适用于以下“类运算符”符号：
类型界限中的&(<T extends Foo & Bar>)。
规则6：在 , : ; 及右括号 ) 后 要有一个空格
规则7： 声明变量时，在类型和变量之间要有一个空格，如int number。

规则8：单目操作符前后不加空格
如："!"、"~"、“++"、"--"、"&"（地址运算符）等前后不需要加空格。

规则9： "."前后不加空格。

2.1.3 代码行字数限制
规则：每行代码的字符数应该不超过125个字符。
说明：较长的语句、表达式或参数（>125字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。

MyEclipse设置方法：
window->preferences->java->code style->formatter->edit->line wrapping->maximum line width 
new一个新的Code Style模板，并将该项设为125
2.1.4 代码行语句限制
规则1：每行代码不能出现多个语句，每行只能有一个语句。

规则2：每行不能声明多个变量，一行只能声明一个变量，且声明变量时应该有初始化值。

2.1.5 定义排序
规则：类属性和类方法不要交叉放置，不同存取范围的属性或者方法也尽量不要交叉放置
格式：

2.2 命名规范要求
2.2.1 包名规范
包名采用域后缀倒置加上自定义的包名，包名采用小写字母。在部门内部应该规划好包名的范围，防止产生冲突。部门内部产品使用部门的名称加上项目名称。产品线的产品使用产品的名称加上模块的名称。
格式：
com.demo.b2b.模块名称
com.demo.bookStore.项目名称
2.2.2 类名规范
规则1: 类名和接口名，是个名词，使用类意义完整的英文描述，每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法，俗称：驼峰命名法。
如：OrderInformation, CustomerList, LogManager, PropertiesManager
规则2：定义接口，名称前面要加I，接口的实现，后面要加Impl，如:
IUserService：表示接口
IUserServiceImpl：表示接口的实现
2.2.3 方法名规范
规则1：方法名是一个动名词，使用类意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。

规则2：方法中，存取属性的方法采用setter 和 getter方法，动作方法采用动词和动宾结构。
规则3：返回类型为boolean的方法，必须以is开头。

格式：
get + 非布尔属性名()
is + 布尔属性名()
set + 属性名()
动词()
动词 + 宾语()
示例：

2.2.4 属性名规范
规则1：属性名使用意义完整的英文描述：第一个单词的字母使用小写、剩余单词首字母大写，其余字母小写。
规则2：属性名不能与方法名相同。
规则3：类型为boolean的属性名称前必须以is开头。
规则4：变量名不应以下划线或美元符号开头。
规则5：含有集合意义的属性命名，尽量包含其复数的意义。
示例：

2.2.5 常量名规范
规则：常量名使用全大写的英文描述，英文单词之间用下划线分隔开，并且使用 static final修饰。
示例：

建议：
对于Long型数据，必须在后面加L标识。
Double类型数据，必须在后面加D标识。
Float类型数据，必须在后面加F标识。
2.2.6 缩写
规则：如果函数名超过15个字母，可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。
如：

2.3 编码规范
2.3.1 方法体长度
规则1：函数体不超过300行。
规则2：一个函数仅完成一个功能，即使简单功能也应该编写方法实现。
说明：虽然为仅用一两行就可完成的功能去编方法好象没有必要，但用方法可使功能明确化，增加程序可读性，亦可方便维护、测试。另外，一个方法体如果太长，可能会造成阅读、理解困难，或是功能复杂没有拆分，这时应该进行方法体的拆分。
2.3.2 文件
规则：一个文件一个类（匿名类除外），文件的长度不超过2000行。
说明：此规范来自sun JAVA规范，
“Files longer than 2000 lines are cumbersome and should be avoided”
规则2：文件的编码类型统一为UTF-8
2.3.3内敛(inline)的表达式
规则：不使用内敛的表达式来进行逻辑判断

说明：这样看起来比较难以阅读和理解。
2.3.4输出调试
规则：在开发中不应该使用System.out.print*等标准输出函数来进行调试和输出信息，而应该使用log API等（SLF4J，log4J等）

2.3.5 包引入
规则1：不使用import * 来导入包的类。应导入具体的类。
说明：使用 * 导入会增加类的加载过程。
规则2：不使用静态导入
说明：使用静态导入容易造成包和类的冲突。
2.3.5 字符串比较
规则1：字符串的比较不要使用“==”，而应该使用equals函数来。
说明：“==”是进行地址的比较，而equals是值比较。如果String是通过

定义，那么str1 == str2为true。Str1.equals(str2)为true。（jvm将他们视为常量，放在常量存储区，str1和str2引用的是同一个地址）。
如果是通过

定义，那么str1 == str2 为false，str1.equals（str2）为true。（JVM将str2放在堆上）。
所以，在比较字符串的值相同时，使用equals方法，而不是“==”

规则2：进行判断、比较时，如果有常量，常量应该放在比较的左边。
说明：将常量放在左边，可以避免由于输入错误（==变为=）造成赋值表达式，判断结果一直为true。

2.3.6 Swtich语句
规则： Switch语句必须有default语句结束。
2.3.7 方法参数个数
规则：方法体的参数个数不能超过7个，否则难以理解和维护。
2.3.8 资源释放
规则：对于需要释放资源的操作，释放方法必须放在finally块中
说明：数据库操作、IO操作等需要使用结束close()的对象必须在try -catch-finally 的finally中。对于异常处理，finally块总会被执行，因此，释放资源必须放在finally中。
2.3.9 异常处理
规则1： 异常捕获后，如果不对该异常进行处理，则应该纪录日志或者使用ex.printStackTrace()打印出来。
规则2：自己抛出的异常必须要填写详细的描述信息。
说明：便于问题定位。
示例：

规则3：一个方法中不应该抛出太多的异常（最好不要超过3个），而应该进行细分处理。
规则4：不要使用catch(Exception e) 和catch (Throwable e)来捕获异常，而应该分层次来捕获（先子异常，在父异常）。除非是在最外层的调用，最后一次异常捕获，否则尽量不使用全局捕获。
2.3.10 运算优先级
规则：注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
说明：防止阅读程序时产生误解，防止因默认的优先级与设计思想不符而导致程序出错。
示例：
下列语句中的表达式

如果书写为：

（1）（2）虽然不会出错，但语句不易理解；（3）造成了判断条件出错。
2.3.11 代码中常量使用
规则1：避免使用不易理解的数字，而用有意义的标识来替代。涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的静态变量来代替。
规则2：系统中使用的常量都应该定义到一个类中，并使用 public static final 来修饰，而不应随意定义。
建议：常量类建议取名为SystemConstants
规则3：常量定义不应该使用接口(interface)，而应该使用一个普通类，并把类的构造函数私有化。
说明：接口主要是用来定义方法的调用，是需要被其他类来实现的，如果接口中只有常量而没有方法，这就违背了接口的意义。为了不让调用者对常量类进行实例化，需要显示声明一个私有的构造方法。
示例：如下的程序可读性差。

以下程序的常量定义未知不符合规范，应该放到一个统一定义常量的类中，并使用JavaDoc的注释方式进行注释，而不应该放在本类中定义。

应改为如下形式：

常量的定义如下：

2.3.12 数组声明
规则：数组声明使用 类型[] 变量 而不是 类型 变量[]

2.4 注释规范
2.4.1 文件注释
规则：文件注释写入文件头部，包名之前的位置。
说明：注意以 /** 开始
示例：
/**
* 注释内容
*/
package m;

文件注释内容包括：版权说明、描述信息、生成日期、修改历史。

2.4.2 类与接口注释
规则：该注释放在 package 关键字之后，class 或者 interface 关键字之前。
说明：方便JavaDoc收集
示例：
package m;
/**
* 注释内容
*/
public class CommManager

类和接口的注释内容：类的注释主要是一句话功能简述、功能详细描述

2.4.3 方法注释
规则：列出方法的一句话功能简述、功能详细描述、输入参数、输出参数、返回值、违例等。
说明：@since 表示从哪个版本开始就有这个方法；@exception或throws 列出可能抛出的异常；

2.4.4 异常注释
规则：对于方法内部用throw语句抛出的异常，必须在方法的注释中标明，对于所调用的其他方法所抛出的异常，选择主要的在注释中说明。 对于非RuntimeException，即throws子句声明会抛出的异常，必须在方法的注释中标明。
说明：异常注释用@exception或@throws表示，在JavaDoc中两者等价，但推荐用@exception标注Runtime异常，@throws标注非Runtime异常。
异常的注释必须说明该异常的含义及什么条件下抛出该异常。
2.4.5 属性注释
规则：属性注释采用JavaDoc的注释方式（/** */）描述该属性的代表的意思和描述。
局部变量的注释可以采用单行注释（//）或多行注释（/* */）的方式。对于意思特别清晰的变量名或属性可以不增加注释。
//属性注释
/**
* 用户类型1：买家，2：卖家，3：后台用户
*/
2.4.6 语句注释
规则：对于注释掉的语句需要说明注释掉的原因、时间，姓名和版本信息。