代码规范
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
（1） 文件长度不应该超过2000行。
（2） 每个方法的长度不应超过53行。
（3） 每行代码长度不应超过120个字符，包括空格。超长的语句应注意折行格式及缩进。
（4） 注释的每行长度不应超过120个字符。
2.5.3 空格的使用
（1） 变量和修饰符之间应该有一个空格。
例子：StringBuffer outHtml//正确。
（4）普通成员方法内部注释（控制结构、代码所起到的作用以及如此编写代码的原因，处理顺序等）。
（4）参数的含义以及其他任何约束或前提条件、字段或属性描述。而对于局部变量，如无特别意义的情况下则不加注释。
2.1.2 具体注释
（1）文件头注释
要求：遵循JavaDoc的规范，在每一个源文件的开头注明该文件的作用,作简要说明,并写上源文件的作者,版权信息编写日期。如果是修改别人编写的源文件，要在修改信息上注明修改者和修改日期。
（3）维护部门交付产品的规范形象。
二．具体规范
2.1 注释
注释是软件可读性的具体表现。程序注释量一般占程序编码量的20%，软件工程要求不少于20%。程序注释不能用抽象的语言，要精确表达出程序的处理说明。避免每行程序都使用注释，可以在一段程序的前面加一段注释，具有明确的处理逻辑。
注释必不可少，但也不应过多，不要被动得为写注释而写注释。
反例：package Gov3.mof_rpt.fasp.core//错误。
2.4.3 类的命名
要求：类名应该是一个名词。类命名以大写字母开头，采用“驼峰”规范，后面每个单词的首字母大写。类名简洁而有意义，使用完整的单词，避免缩写词（除非该缩写词被广泛使用如URL）。对于BPO,BO,DAO层中的类后面增加相应简写后缀的方式。如UserManagerBPO、UserBO、UserDAO。
（2） 等号两边应该各有一个空格。
例子： Stringstr = new String();//正确。
反例： Stringstr=new String();//错误。
（3） 类，接口，方法以及if,else,while,for,do,switch,try,catch语句中，左大括号应与圆括号同行，并用一个空格隔开。即左大括号“{”位于声明语句同行的末尾，并且有一个空格，右大括号“}”另起一行。
注：这是一种习惯的简便用法，容易区分。
2.5 书写格式规范
2.5.1 空行
（1） 每个文件末尾应该有一个空行。
（2） 不得出现无规则的空行，比如连续十个空行。
（3） 每个块之间增加一个空行。
（4） 属性和方法之间增加一个空行。
（5） import导入包时，相关联的包组织在一起，通过一个空行隔开。
2.5.2 行数及行宽限制
一个文件由被空行分割而成的段落以及标识每个段落的可选注释共同组成。超过2000行的程序难以阅读，应该尽量避免。
Java源文件结构应该遵循下面的结构：
文件注释
包声明
导入声明
类注释
类声明
注意：
（1）导入多个类时，系统类放在上面，非系统类放在下面，中间以空行分开，按字母升序排列。
（2）在导入声明的时候，应避免使用通配符(如:import java.util.*)，而要用完整的导入声明(如:import java.util.Vector)。
（5）在方法名与其参数列表之前的左括号”(”之间不要有空格。
例子： addRecord(name, age)//正确。
反例：addRecord( name,age)//错误的写法。
注：可以在IDE中设置，或者导入formatter模板，对代码格式化。
注：sun的代码规范约定，命名属性访问方法遵守JavaBeans约定。在写JavaBean时该规则实际是强制的。
（2）is的用法
要求：is应当在Boolean变量命名和访问方法中使用。
例子：isSet,isVisible,isFinished,isFound,isOpen.
（3）循环变量
要求：方法内部循环变量应当使用I,j,k。
2.1.1 需要注释的部分
（1）文件头注释，文件创建及修改记录，版权归属，作者以及修订者，以及对文件的简短描述。
（2）类的目的（即类所完成的功能）、设置接口的目的以及应如何被使用。
（3）成员方法注释（对于设置与获取成员方法，在成员变量已有说明的情况下，可以不加注释；普通成员方法要求说明完成功能，参数含义以及返回值）。
2.1.3 修改缺陷注释
在修改bug时，要带bug号和简短说明时间和修改者，加上修改开始结束，避免发生修改覆盖的情况，导致bug的反复。
例子 :
//张三 2009-07-15 BUG-1388 修改开始 修改判断状态
*****
*****
//张三2009-07-15 BUG-1388 修改结束
格式
2.2 源文件结构
（5）行尾注释
要求：尽量不使用行尾注释。如需使用，必须与代码末端保持一个空格。
例子：return true;//注释内容//这是正确的写法。
反例：return true;//注释内容//错误写法。不能借助模板格式化此处，需要代//码编写者自行注意。
（5）常用的javadoc文档标签有
@author,@throws,@param,@deprecated,@return,@link,@see,@since,@version等
对于BPO、BO、DAO层中的JAVA文件后面增加相应简写后缀的方式。如UserManagerBPO、UserBO、UserDAO。
2.4.2 包的命名
要求：用财政部的国际域名的倒转的小写字母作为包的根，再加上项目名和各个模块的名称作为包名。包的名称只能是小写字母并且没有下划线。
例子：packagegov.mof.fasp.core//正确
例子：COLOR_RED//正确。
2.4.9 数组的命名
要求：变量表示集合，要用复数形式。
例子：String[]users//正确。
2.4.10 特定命名规范
（1）get/set方法
要求：get/set方法是必须在直接访问变量时使用。
例子：employee.getName();//正确
employee.setName(name);//正确
例子：privateString userID;//正确。
privateString userName;//正确。
注意：变量命名应遵循如下的原则：
a)标识符应当直观且可以拼读，可望文知义，容易理解和接受。
b)标识符的长度应当符合“min-length&&max-infomation”原则。
c)命名规则尽量与所采用的操作系统或开发工具的风格保持一致。
例子：userID//如果已经定义了userID，就不要定义useID,避免发生混淆。
（5）要求：除定义常量外，不使用下划线。
例子：AUTHORVAL_WRITE//定义常量表示可写权限
反例：user_ID//错误。
2.4.2 目录和文件的命名
目录命名以小写字母开头，后面每个单词的首字母大写。
文件命名以大写字母开头，后面每个单词的首字母大写。如DeclareDetail.java。
2.4 命名
2.4.1 总体原则
（1）要求：必须用完整的有意义的英文名称，不要用拼音，尽量少用阿拉伯数字
例子：userID//正确，含义明确。
反例：yonghuID//反例1。使用拼音。
g//反例2。含义不明，代码阅读困难。
（2）要求：尽量采用相关领域的术语。
例子：accountName//正确。可以表示账户名。
反例：userName//在表示“账户名”时避免。表达尽量使用精确的，不容易产生歧义的术语。
（3）要求：尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一。
例子：rpt//在工程中统一表示报表
（4）要求：避免使用长的名字（小于 15 个字母是个好主意）。
（5）要求：避免使用类似的名字，或者仅仅是大小写不同的名字。
例子：
/**
* @ClassName:类（或接口）名
* @Description: Description of this class
* @author作者于时间
*/
（2）方法的注释
要求：遵循JavaDoc的规范，在每个方法的前部用块注释的方法描述此方法的作用，传入，传出参数的类型和作用，以及需要捕获的错误。
例子：
/**
* Leabharlann BaiduTitle:文件名
* @Copyright (C)年份龙图软件
* @Description:文件信息描述
* @Revision History:
* @Revision版本号日期作者.
*/
（2）类和接口的注释
要求：遵循JavaDoc的规范，在每一个类的开头注明该类的作用，作简要说明，并写上作者，编写日期。
1.2 开发规范的重要性
（1）减少维护成本；
一个软件的生命周期中，80%的花费在于维护，另一方面，几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护，规范的编码减少人员变动带来的维护成本。
（2）改善软件的可读性
可以让程序员尽快而彻底地理解新的代码。在一个团队中，代码也容易在程序员之间共享。
try{
…
} catch(Exception e){
…
}finally {
…
}
f) switch语句
switch(value){
case 0:
…
break;
…
default:
…
break;
}
（4）不要出现无意义的空格。
在行尾，注释末端，或者某一个空行中不要出现无意义的空格，虽然这些不可见字符不会影响编译，但是不会通过代码检查。
例子：private Stringusername;//正确。
2.4.7 方法的命名
要求：方法命名一般采用动词加名词，如果可能的话，使用和要赋值的字段一样的名字。方法的名字必须用一个小写字母开头。后面的单词用大写字母开头。
例子：intgetSize()//正确。
2.4.8 常量的命名
要求：命名常量时用大写的字母并且每个单词之间用下划线分割。
d)程序中不要出现仅靠大小写区分的相似的标识符。
e)变量名称字符应控制在15个以内。
f)尽量避免名字中出现数字编号，如Value1,Value2。
g) 如果两个变量类型一样，就用类型做前缀。如：
User userOne;
User userTwo;
2.4.6 类的属性命名
要求：类属性命名全部采用小写字母，如果需要持久化，要保证和数据库中的字段名称一样；类属性和数据库中的字段前都不用额外的加f。
例子：classUserManagerBPO
2.4.4 接口的命名
要求：接口名称以I开头，I之后的名称遵照类的命名规范。
例子：public interface IRptDataSetService//正确。表示“报表数据集接口”。
2.4.5 变量的命名
要求：变量必须采用驼峰命名方式命名，起始必须字符小写，之后的每个单词首字母大写。
这样做的好处是使后来阅读代码的人可以很清楚的知道这个程序中用到了那些类并且防止后来的人导入的类和你现在用的类有冲突，另外，编译器在有通配符的情况下，搜索会由额外的开销，消耗资源。
2.3 类结构
类的声明应该遵循下面的结构：
类变量声明及注释
实例变量声明及注释
类构造声明及注释
类方法声明及注释
实例方法声明及注释
例子：
ａ）类或接口声明:
public class MyClass {
…
}
ｂ）方法声明:
void method(int j){
…
}
ｃ）for循环：
for(int i=0;i<MAX_NUM;i++){
…
}
ｄ）if…else语句：
if (…) {
…
} else if (…){
…
}
ｅ）try…catch语句
一．规范简介
1.1 目的
所有的程序开发手册都包含了各种规则。一些习惯自由程序人员可能对这些规则很不适应，但是在多个开发人员共同写作的情况下，这些规则是必需的。这不仅仅是为了开发效率来考虑，而且也是为了后期维护考虑。
本规范正是为培养规范设计和编程，养成良好的习惯，增强软件产品的稳定，健壮，可靠性；同时也为了提高软件的可读性，可以让程序员尽快而彻底地理解新的代码，使产品可维护性提高而制定的规范。
例如：
/**
* @Description:方法描述
* @param menus参数意义
* @return返回值
* @throws AppException错误描述
*/
（3）行注释
要求：使用//…的注释方法来注释需要表明的内容。并且把注释的内容放在需要注释的代码的前面一行或同一行。
（4）块注释
要求：使用/**和*/注释的方法来注释需要表明的内容。并且把注释的内容放在需要注释的代码的前面。
（2） 每个方法的长度不应超过53行。
（3） 每行代码长度不应超过120个字符，包括空格。超长的语句应注意折行格式及缩进。
（4） 注释的每行长度不应超过120个字符。
2.5.3 空格的使用
（1） 变量和修饰符之间应该有一个空格。
例子：StringBuffer outHtml//正确。
（4）普通成员方法内部注释（控制结构、代码所起到的作用以及如此编写代码的原因，处理顺序等）。
（4）参数的含义以及其他任何约束或前提条件、字段或属性描述。而对于局部变量，如无特别意义的情况下则不加注释。
2.1.2 具体注释
（1）文件头注释
要求：遵循JavaDoc的规范，在每一个源文件的开头注明该文件的作用,作简要说明,并写上源文件的作者,版权信息编写日期。如果是修改别人编写的源文件，要在修改信息上注明修改者和修改日期。
（3）维护部门交付产品的规范形象。
二．具体规范
2.1 注释
注释是软件可读性的具体表现。程序注释量一般占程序编码量的20%，软件工程要求不少于20%。程序注释不能用抽象的语言，要精确表达出程序的处理说明。避免每行程序都使用注释，可以在一段程序的前面加一段注释，具有明确的处理逻辑。
注释必不可少，但也不应过多，不要被动得为写注释而写注释。
反例：package Gov3.mof_rpt.fasp.core//错误。
2.4.3 类的命名
要求：类名应该是一个名词。类命名以大写字母开头，采用“驼峰”规范，后面每个单词的首字母大写。类名简洁而有意义，使用完整的单词，避免缩写词（除非该缩写词被广泛使用如URL）。对于BPO,BO,DAO层中的类后面增加相应简写后缀的方式。如UserManagerBPO、UserBO、UserDAO。
（2） 等号两边应该各有一个空格。
例子： Stringstr = new String();//正确。
反例： Stringstr=new String();//错误。
（3） 类，接口，方法以及if,else,while,for,do,switch,try,catch语句中，左大括号应与圆括号同行，并用一个空格隔开。即左大括号“{”位于声明语句同行的末尾，并且有一个空格，右大括号“}”另起一行。
注：这是一种习惯的简便用法，容易区分。
2.5 书写格式规范
2.5.1 空行
（1） 每个文件末尾应该有一个空行。
（2） 不得出现无规则的空行，比如连续十个空行。
（3） 每个块之间增加一个空行。
（4） 属性和方法之间增加一个空行。
（5） import导入包时，相关联的包组织在一起，通过一个空行隔开。
2.5.2 行数及行宽限制
一个文件由被空行分割而成的段落以及标识每个段落的可选注释共同组成。超过2000行的程序难以阅读，应该尽量避免。
Java源文件结构应该遵循下面的结构：
文件注释
包声明
导入声明
类注释
类声明
注意：
（1）导入多个类时，系统类放在上面，非系统类放在下面，中间以空行分开，按字母升序排列。
（2）在导入声明的时候，应避免使用通配符(如:import java.util.*)，而要用完整的导入声明(如:import java.util.Vector)。
（5）在方法名与其参数列表之前的左括号”(”之间不要有空格。
例子： addRecord(name, age)//正确。
反例：addRecord( name,age)//错误的写法。
注：可以在IDE中设置，或者导入formatter模板，对代码格式化。
注：sun的代码规范约定，命名属性访问方法遵守JavaBeans约定。在写JavaBean时该规则实际是强制的。
（2）is的用法
要求：is应当在Boolean变量命名和访问方法中使用。
例子：isSet,isVisible,isFinished,isFound,isOpen.
（3）循环变量
要求：方法内部循环变量应当使用I,j,k。
2.1.1 需要注释的部分
（1）文件头注释，文件创建及修改记录，版权归属，作者以及修订者，以及对文件的简短描述。
（2）类的目的（即类所完成的功能）、设置接口的目的以及应如何被使用。
（3）成员方法注释（对于设置与获取成员方法，在成员变量已有说明的情况下，可以不加注释；普通成员方法要求说明完成功能，参数含义以及返回值）。
2.1.3 修改缺陷注释
在修改bug时，要带bug号和简短说明时间和修改者，加上修改开始结束，避免发生修改覆盖的情况，导致bug的反复。
例子 :
//张三 2009-07-15 BUG-1388 修改开始 修改判断状态
*****
*****
//张三2009-07-15 BUG-1388 修改结束
格式
2.2 源文件结构
（5）行尾注释
要求：尽量不使用行尾注释。如需使用，必须与代码末端保持一个空格。
例子：return true;//注释内容//这是正确的写法。
反例：return true;//注释内容//错误写法。不能借助模板格式化此处，需要代//码编写者自行注意。
（5）常用的javadoc文档标签有
@author,@throws,@param,@deprecated,@return,@link,@see,@since,@version等
对于BPO、BO、DAO层中的JAVA文件后面增加相应简写后缀的方式。如UserManagerBPO、UserBO、UserDAO。
2.4.2 包的命名
要求：用财政部的国际域名的倒转的小写字母作为包的根，再加上项目名和各个模块的名称作为包名。包的名称只能是小写字母并且没有下划线。
例子：packagegov.mof.fasp.core//正确
例子：COLOR_RED//正确。
2.4.9 数组的命名
要求：变量表示集合，要用复数形式。
例子：String[]users//正确。
2.4.10 特定命名规范
（1）get/set方法
要求：get/set方法是必须在直接访问变量时使用。
例子：employee.getName();//正确
employee.setName(name);//正确
例子：privateString userID;//正确。
privateString userName;//正确。
注意：变量命名应遵循如下的原则：
a)标识符应当直观且可以拼读，可望文知义，容易理解和接受。
b)标识符的长度应当符合“min-length&&max-infomation”原则。
c)命名规则尽量与所采用的操作系统或开发工具的风格保持一致。
例子：userID//如果已经定义了userID，就不要定义useID,避免发生混淆。
（5）要求：除定义常量外，不使用下划线。
例子：AUTHORVAL_WRITE//定义常量表示可写权限
反例：user_ID//错误。
2.4.2 目录和文件的命名
目录命名以小写字母开头，后面每个单词的首字母大写。
文件命名以大写字母开头，后面每个单词的首字母大写。如DeclareDetail.java。
2.4 命名
2.4.1 总体原则
（1）要求：必须用完整的有意义的英文名称，不要用拼音，尽量少用阿拉伯数字
例子：userID//正确，含义明确。
反例：yonghuID//反例1。使用拼音。
g//反例2。含义不明，代码阅读困难。
（2）要求：尽量采用相关领域的术语。
例子：accountName//正确。可以表示账户名。
反例：userName//在表示“账户名”时避免。表达尽量使用精确的，不容易产生歧义的术语。
（3）要求：尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一。
例子：rpt//在工程中统一表示报表
（4）要求：避免使用长的名字（小于 15 个字母是个好主意）。
（5）要求：避免使用类似的名字，或者仅仅是大小写不同的名字。
例子：
/**
* @ClassName:类（或接口）名
* @Description: Description of this class
* @author作者于时间
*/
（2）方法的注释
要求：遵循JavaDoc的规范，在每个方法的前部用块注释的方法描述此方法的作用，传入，传出参数的类型和作用，以及需要捕获的错误。
例子：
/**
* Leabharlann BaiduTitle:文件名
* @Copyright (C)年份龙图软件
* @Description:文件信息描述
* @Revision History:
* @Revision版本号日期作者.
*/
（2）类和接口的注释
要求：遵循JavaDoc的规范，在每一个类的开头注明该类的作用，作简要说明，并写上作者，编写日期。
1.2 开发规范的重要性
（1）减少维护成本；
一个软件的生命周期中，80%的花费在于维护，另一方面，几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护，规范的编码减少人员变动带来的维护成本。
（2）改善软件的可读性
可以让程序员尽快而彻底地理解新的代码。在一个团队中，代码也容易在程序员之间共享。
try{
…
} catch(Exception e){
…
}finally {
…
}
f) switch语句
switch(value){
case 0:
…
break;
…
default:
…
break;
}
（4）不要出现无意义的空格。
在行尾，注释末端，或者某一个空行中不要出现无意义的空格，虽然这些不可见字符不会影响编译，但是不会通过代码检查。
例子：private Stringusername;//正确。
2.4.7 方法的命名
要求：方法命名一般采用动词加名词，如果可能的话，使用和要赋值的字段一样的名字。方法的名字必须用一个小写字母开头。后面的单词用大写字母开头。
例子：intgetSize()//正确。
2.4.8 常量的命名
要求：命名常量时用大写的字母并且每个单词之间用下划线分割。
d)程序中不要出现仅靠大小写区分的相似的标识符。
e)变量名称字符应控制在15个以内。
f)尽量避免名字中出现数字编号，如Value1,Value2。
g) 如果两个变量类型一样，就用类型做前缀。如：
User userOne;
User userTwo;
2.4.6 类的属性命名
要求：类属性命名全部采用小写字母，如果需要持久化，要保证和数据库中的字段名称一样；类属性和数据库中的字段前都不用额外的加f。
例子：classUserManagerBPO
2.4.4 接口的命名
要求：接口名称以I开头，I之后的名称遵照类的命名规范。
例子：public interface IRptDataSetService//正确。表示“报表数据集接口”。
2.4.5 变量的命名
要求：变量必须采用驼峰命名方式命名，起始必须字符小写，之后的每个单词首字母大写。
这样做的好处是使后来阅读代码的人可以很清楚的知道这个程序中用到了那些类并且防止后来的人导入的类和你现在用的类有冲突，另外，编译器在有通配符的情况下，搜索会由额外的开销，消耗资源。
2.3 类结构
类的声明应该遵循下面的结构：
类变量声明及注释
实例变量声明及注释
类构造声明及注释
类方法声明及注释
实例方法声明及注释
例子：
ａ）类或接口声明:
public class MyClass {
…
}
ｂ）方法声明:
void method(int j){
…
}
ｃ）for循环：
for(int i=0;i<MAX_NUM;i++){
…
}
ｄ）if…else语句：
if (…) {
…
} else if (…){
…
}
ｅ）try…catch语句
一．规范简介
1.1 目的
所有的程序开发手册都包含了各种规则。一些习惯自由程序人员可能对这些规则很不适应，但是在多个开发人员共同写作的情况下，这些规则是必需的。这不仅仅是为了开发效率来考虑，而且也是为了后期维护考虑。
本规范正是为培养规范设计和编程，养成良好的习惯，增强软件产品的稳定，健壮，可靠性；同时也为了提高软件的可读性，可以让程序员尽快而彻底地理解新的代码，使产品可维护性提高而制定的规范。
例如：
/**
* @Description:方法描述
* @param menus参数意义
* @return返回值
* @throws AppException错误描述
*/
（3）行注释
要求：使用//…的注释方法来注释需要表明的内容。并且把注释的内容放在需要注释的代码的前面一行或同一行。
（4）块注释
要求：使用/**和*/注释的方法来注释需要表明的内容。并且把注释的内容放在需要注释的代码的前面。