java编码规范.docx

java编码规范.docx

《java编码规范.docx》由会员分享，可在线阅读，更多相关《java编码规范.docx（13页珍藏版）》请在冰豆网上搜索。

java编码规范

开发过程中，建立JAVA开发规范，统一JAVA代码的编码风格，可以增加清晰性和可阅读性，便于走查和维护！

一工程编码

建议工程名表意明确

工程项目编码格式使用UTF-8

文件的编码类型统一为UTF-8

二开发编码规范

2.1排版规范要求

2.1.1缩进风格

规则：

代码采用缩进风格，tab用4个空格替代。

代码中避免使用tab。

说明：

用不同的编辑器阅读程序时，因TAB键所设置的空格数目不同而造成程序布局不整齐。

在eclipse和myeclipse中可以设置tab转换为空格。

配置方法如下：

（1）点击window->preferences->General->Editors->TextEditors，设置如下界面中红色标记内容。

2.1.2分界符

2.2.2.1大括号｛｝

规则1：

大括号与if,else,for,do,while语句一起使用，即使只有一条语句（或是空），也应该把大括号写上。

示例：

规则2：

左大括号前不换行，左大括号后换行，右大括号前换行

如果右大括号是一个语句、函数体或类的终止，则右大括号后换行;否则不换行。

例如，如果右大括号后面是else，catch或逗号，则不换行。

示例：

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

2.2.2.2空格

规则1：

除方法的声明和调用外，小括号前一定要有一个空格。

规则2：

分隔任何保留字与紧随其后的左括号（如if,forcatch等。

规则3：

分隔任何保留字与其前面的右大括号}如else,catch。

规则4：

在任何左大括号前{要有空格

规则5：

在任何二元或三元运算符的两侧。

这也适用于以下“类运算符”符号：

类型界限中的&（）。

规则6：

在,:

;及右括号）后要有一个空格

规则7：

声明变量时，在类型和变量之间要有一个空格，如int number。

规则8：

单目操作符前后不加空格

如：

"!

"、"~"、“++"、"--"、"&"（地址运算符）等前后不需要加空格。

规则9：

"."前后不加空格。

2.1.3代码行字数限制

规则：

每行代码的字符数应该不超过125个字符。

说明：

较长的语句、表达式或参数（>125字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。

MyEclipse设置方法：

window->preferences->java->codestyle->formatter->edit->linewrapping->maximumlinewidth 

new一个新的CodeStyle模板，并将该项设为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常量名规范

规则：

常量名使用全大写的英文描述，英文单词之间用下划线分隔开，并且使用staticfinal修饰。

示例：

建议：

对于Long型数据，必须在后面加L标识。

Double类型数据，必须在后面加D标识。

Float类型数据，必须在后面加F标识。

2.2.6缩写

规则：

如果函数名超过15个字母，可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。

如：

2.3编码规范

2.3.1方法体长度

规则1：

函数体不超过300行。

规则2：

一个函数仅完成一个功能，即使简单功能也应该编写方法实现。

说明：

虽然为仅用一两行就可完成的功能去编方法好象没有必要，但用方法可使功能明确化，增加程序可读性，亦可方便维护、测试。

另外，一个方法体如果太长，可能会造成阅读、理解困难，或是功能复杂没有拆分，这时应该进行方法体的拆分。

2.3.2文件

规则：

一个文件一个类（匿名类除外），文件的长度不超过2000行。

说明：

此规范来自sunJAVA规范，

“Fileslongerthan2000linesarecumbersomeandshouldbeavoided”

规则2：

文件的编码类型统一为UTF-8

2.3.3内敛（inline）的表达式

规则：

不使用内敛的表达式来进行逻辑判断

说明：

这样看起来比较难以阅读和理解。

2.3.4输出调试

规则：

在开发中不应该使用System.out.print*等标准输出函数来进行调试和输出信息，而应该使用logAPI等（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.6Swtich语句

规则：

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（Exceptione）和catch（Throwablee）来捕获异常，而应该分层次来捕获（先子异常，在父异常）。

除非是在最外层的调用，最后一次异常捕获，否则尽量不使用全局捕获。

2.3.10运算优先级

规则：

注意运算符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。

说明：

防止阅读程序时产生误解，防止因默认的优先级与设计思想不符而导致程序出错。

示例：

下列语句中的表达式

如果书写为：

（1）

（2）虽然不会出错，但语句不易理解；（3）造成了判断条件出错。

2.3.11代码中常量使用

规则1：

避免使用不易理解的数字，而用有意义的标识来替代。

涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的静态变量来代替。

规则2：

系统中使用的常量都应该定义到一个类中，并使用publicstaticfinal来修饰，而不应随意定义。

建议：

常量类建议取名为SystemConstants

规则3：

常量定义不应该使用接口（interface），而应该使用一个普通类，并把类的构造函数私有化。

说明：

接口主要是用来定义方法的调用，是需要被其他类来实现的，如果接口中只有常量而没有方法，这就违背了接口的意义。

为了不让调用者对常量类进行实例化，需要显示声明一个私有的构造方法。

示例：

如下的程序可读性差。

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

应改为如下形式：

常量的定义如下：

2.3.12数组声明

规则：

数组声明使用类型[]变量而不是类型变量[]

2.4注释规范

2.4.1文件注释

规则：

文件注释写入文件头部，包名之前的位置。

说明：

注意以/**开始

示例：

/**

*注释内容

*/

packagem;

文件注释内容包括：

版权说明、描述信息、生成日期、修改历史。

2.4.2类与接口注释

规则：

该注释放在package关键字之后，class或者interface关键字之前。

说明：

方便JavaDoc收集

示例：

packagem;

/**

*注释内容

*/

publicclassCommManager

类和接口的注释内容：

类的注释主要是一句话功能简述、功能详细描述

2.4.3方法注释

规则：

列出方法的一句话功能简述、功能详细描述、输入参数、输出参数、返回值、违例等。

说明：

@since表示从哪个版本开始就有这个方法；@exception或throws列出可能抛出的异