JAVA编码规范.docx
《JAVA编码规范.docx》由会员分享，可在线阅读，更多相关《JAVA编码规范.docx（10页珍藏版）》请在冰豆网上搜索。
JAVA编码规范
JAVA编码规范
修订记录
版本
版本日期
修订者
修订说明
V1.0
2010-07-07
那建林
创建
V1.1
2010-07-23
那建林
添加实例
V1.2
2010-07-24
陈晔
校正、排版、发布
目录
1前言3
1.1目的3
2Java编码通用规则3
2.1命名3
2.1.1包（Package）3
2.1.2类（Class）3
2.1.3字段（field）4
2.1.4静态常量字段（staticfinalfield）4
2.1.5局部常量（localvariable）4
2.1.6方法（method）4
2.1.7参数（parameter）4
2.1.8集合（Collection）5
2.2代码风格5
2.2.1文件注释5
2.2.2包和导入声明5
2.2.3换行和缩进5
2.2.4代码块5
2.2.5类和接口6
2.2.6字段6
2.2.7方法7
2.2.8判断、循环、异常处理语句7
2.2.9运算符8
2.2.10数组8
2.3程序编写8
2.3.1异常处理8
2.3.2状态判断9
2.3.3工具类9
2.3.4System.out和System.err10
2.3.5静态方法10
2.3.6StringBuffer10
2.3.7代码复用10
2.3.8垃圾回收10
1前言
1.1目的
代码质量的好坏关系到将来代码的维护、性能、可移植性等问题，文中指出了开发人员常犯的影响代码质量的错误，并举例供程序员使用以防止类似的错误发生，并减少将来用于程序诊断及优化的时间。
同时，良好的编码习惯有助于标准化程序的结构和编码风格，使源代码对于自己和别人都易读和易懂。
在开发周期中越早使用恰当的编码规定，将会最大程度的提高项目的生产率。
良好的编码习惯除了代码格式，详细的注释外，还应该包括使用有助于提高程序效率的编码方式。
本文档的主要目的是引导新的程序员建立一个规范、良好的编码习惯。
2Java编码通用规则
2.1命名
2.1.1包（Package）
⏹包的名字应该能够说明包的用途，通常应是名词或名词短语。
并且包的名字应该全部由小写字母构成。
【例如】container
⏹如果包的用途必须由两个或多个单词才能描述清楚，可以直接将这些单词连接作为包名。
【例如】webcontainer
⏹如果连接后的包名太长，可以使用单词的缩写（缩写必须不会引起歧义）或取每个单词的首字母。
【例如】websvr或ws
2.1.2类（Class）
⏹类的名字应该能够说明类的用途，通常应是名词或名词短语。
类的名字由若干单词连接而成，每个单词的首字母应大写，其他字母小写。
【例如】Server、WebServer
⏹如果某个词是一个缩写形式，则这个词应全部大写。
【例如】HTTPServer、URLBuilder
2.1.3字段（field）
⏹字段的名字应该能够说明该字段的用途，通常取名词或名词短语，也可能是形容词。
字段的名字由若干单词连接构成，第一个单词应全部小写，其余单词的首字母大写。
【例如】color、backgroundColor或enabled
2.1.4静态常量字段（staticfinalfield）
⏹静态常量字段的名字应该能够说明该字段的用途，通常取名词或名词短语，也可能是限定性的形容词或副词。
⏹静态常量字段的名字如果只有一个单词，则该单词应全部大写。
【例如】NAME、HORIZONTAL
⏹静态常量字段如果由若干单词描述，则其名字应由这些单词以下划线“_”连接构成，每个单词均大写。
【例如】USER_NAME、SCROLLBARS_NEVER
2.1.5局部常量（localvariable）
对于作用域较大（变量的有效范围超过5行代码）的局部变量，其命名应遵循上述“字段”的命名规则；对于作用域较小（变量的有效范围不超过5行代码）的局部变量，在不至于引起混淆并且不会降低代码可读性的前提下，可以取简单的名字。
【例如】可以使用“i”作为小循环的循环变量名。
2.1.6方法（method）
⏹所有的方法名（构造函数除外）都应能说明方法的用途，通常取动词或动词短语，也可能是名词或名词短语。
方法名由若干单词连接而成，第一个单词应全部小写，其余单词的首字母大写。
【例如】connect、paintBorder、hashCode
⏹对于以名词或名词短语命名的方法，建议改成动词或动词短语形式。
【例如】尽量不要使用“color”这样的方法名，而是使用“getColor”。
⏹如果方法是用动词或动词短语来描述的，并且该方法是用来做判断或比较，返回一个boolean型的返回值，那么方法名中的动词应取单数第三人称形式。
【例如】equals、hasNext
2.1.7参数（parameter）
参数是指方法参数列表中的形参。
参数的命名应遵循上述“字段”的命名规则。
2.1.8集合（Collection）
对于集合或数组类型的变量，其名称应尽量取复数形式，相应的存取方法中也应使用复数形式。
【例如】
Listchildren
CollectiongetAttributes（）
2.2代码风格
2.2.1文件注释
每个Java源程序文件的开头都应加入该文件的javadoc注释，包含文件的作者、版本、创建时间。
【例如】
/**
*desc:
*
*ver.dateauthor
*----------------------------------
*v0.1Jul19,2010xxx
*----------------------------------
*/
2.2.2包和导入声明
文件注释之后，应留一个空行，在空行后加入包声明；包声明之后加入一个空行，空行后加入导入声明。
将“java”开头的类首先导入，其次导入“javax”开头的类，然后倒入第三方工具包中的类，最后导入自己开发的其他类。
2.2.3换行和缩进
源代码中一行的长度不要超过80个字符。
超出则应拆分或适当换行。
代码的缩进量应为4个字符，可以使用4个空格代替，也可以使用宽度为4个字符的Tab符代替。
2.2.4代码块
代码块是指用“{”和“}”包围的一段代码。
代码块用于类的定义、方法的定义、循环的定义、条件分支的定义等情况。
代码块中的“{”应置于上一行代码的行末，并且与之前的代码之间用没有分隔；代码块中的内容则应在换行并缩进之后书写；代码块最后的“}”应单独占一行，并与代码块开始的"{"所处的行缩进位置相同。
【例如】
for（inti=0;i<10;i++）{
doSomeThing（）;
}
2.2.5类和接口
每个类和接口的声明之前应加入类的javadoc注释。
类或接口的声明（包括“class”、“interface”、“extends”、“implements”等关键字）应尽量在一行中完成，如果超出一行需要换行，则应在“extends”或“implements”等关键字之前换行，换行后应缩进。
类或接口的定义应符合上述“代码块”的规则。
【例如】
/**
*@authorJoshBloch
*@authorNealGafter
*@version1.49,04/21/06
*/
publicinterfaceCollectionextendsIterable{
……
}
2.2.6字段
每个public的字段声明之前必须加入javadoc注释；其他字段可以不要javadoc注释。
每个字段的声明应单独占一行，不建议用一行定义多个字段。
【例如】
应写成：
intfirstField;
intsecondField;
intthirdField;
而不要写成：
intfirstField,secondField,thirdField;
2.2.7方法
方法的声明之前应加入javadoc注释。
对于方法的声明部分，方法名与其之后的“（”之间不应有空格分隔；“（”或“）”与参数列表中的形参声明之间不应有空格分隔；每个形参声明与其之后的“，”之间也不应有空格分隔；参数列表中的“，”与下一个形参声明之间应用一个空格分隔。
方法的定义部分则应遵循上述“代码块”的规则。
【例如】
/**
*
*@paramparam1
*@paramparam2
*@paramparam3
*@return
*@throwsException
*/
publicintsomeMethod（intparam1,intparam2,intparam3）throwsException{
……
}
2.2.8判断、循环、异常处理语句
判断、循环、异常处理语句是指if（else）、switch、for、while（do）、try（catch）等语句。
这些语句中会用到括号，与方法参数列表中的括号不同，这些语句中的括号是跟随在某个Java关键字之后的。
关键字与其之后的"（"之间应由一个空个分隔；“（”或“）”与其中的内容之间不应有空格分隔；对于for语句而言，括号中的每个分号“；”前面不应有空格，后面则应有一个空格。
【例如】
if（a>b）
for（inti=0;i<10;i++）
catch（Exceptione）
这些语句后面如果跟简单语句，必须换行并缩进。
【例如】
if（a>b）
doSomeThing（）;
否则，后面跟随的内容应符合"代码块"的规则。
【例如】
while（a>b）{
a--;
b++;
}
try（catch）语句的例子如下：
try{
doSomeThing（）;
}catch（Exceptione）{
handleException（e）;
}
2.2.9运算符
每个运算符与操作数之间都应有空格分隔。
【例如】
b=true
a>b&&a不能写成：
b=true
a>b&&a
2.2.10数组
数组的定义应写成：
int[]indices;
而不要写成：
intindices[];
2.3程序编写
2.3.1异常处理
如果代码执行的过程中，捕获了一个异常，绝对不能简单地将这个异常“吃”掉或是打印一些类似于“1111111”的信息，而是应该谨慎对待。
因为异常包含了程序执行过程中的原始错误信息，良好的异常处理策略可以为后期的调试、维护等工作带来极大的便利。
每个异常在捕获时都要注明抛出此异常的原因。
从功能的角度来看，代码中捕获的异常通常分为两种情况：
可以预见的和不可预见的。
不可预见的异常是指在代码编写期间没有考虑到或无法考虑到的异常情况，例如进行数据库访问时连接突然中断。
可以预见的异常是指代码编写期间就可以考虑到的“合理”异常，例如将字符串解析为数字时引发的NumberFormatException。
异常的处理应该以方法为单位，也就是说，某个方法内部捕获到一个异常时，应该由该方法决定如何处理此异常。
对于可以预见的异常，可以采取两种处理策略：
处理异常或抛出异常。
处理异常是指该异常在当前方法的处理能力之内，该方法可以自行处理此异常。
例如用户输入某个字符串后，要求程序自行解析，如果为数字，则视为用户的身份号码；如果不为数字，则视为用户的姓名。
假定解析用户输入字符串的方法名为parseInput，那么在parseInput方法执行的过程中，可能会引发NumberFormatException。
这个异常对于parseInput而言是可以预见的，并且是它可以自行处理的，那么它应该自己捕获此异常，而不必将其另行抛出。
假如在上面的例子中，用户姓名的合法性本身还有一套校验规则，那么在parseInput方法中处理了NumberFormatException之后，执行用户姓名校验时还有可能引发异常。
这个异常虽然也是可以预见的，但是已经超出了parseInput方法的职责范围，它应该将此异常继续抛出。
抛出的异常会被更外围的方法捕获，由它们最终决定如何处理该异常，例如提示用户或中止程序。
对于不可预见的异常，只有一种策略可以采用：
继续抛出。
对于每个方法而言，处理异常的原则就是：
在自己职责范围之内的异常，一定要自己处理，不能抛出；在自己职责范围之外的异常，则一定要抛出，绝对不能自行处理。
应该选择“处理异常”还是“抛出异常”并没有严格的标准，往往要依靠经验并从实际的需求出发。
但是通常而言，选择“处理异常”策略的方法都属于程序“较外围”（即在调用堆栈中处于比较底层）的业务控制方法，因为只有它们知道业务需求，只有它们才能决定发生某个异常时应该通知用户、记入日志还是中止程序。
对于大多数工具方法或通用方法而言，它们并不了解实际的业务需求，在异常发生时，它们最好的选择就是“抛出异常”策略，将异常原封不动地抛给外围的业务控制方法，由它们作出决定。
2.3.2状态判断
在可能的情况下，应该尽量使用异常而不是返回值来表示某个方法的执行状态。
某个方法可以在任何需要的时候抛出异常，而不仅仅是在发生错误的时候。
例如一个校验用户身份的方法如下：
booleanauthenticate（Stringuser,Stringpassword）;
使用该方法校验用户身份只能返回true或false，表示用户校验通过与否，对于校验不通过的情况，该方法无法返回更多的信息。
如果将该方法设计成如下的样子：
voidauthenticate（Stringuser,Stringpassword）throwsException;
调用该方法时，如果没有引发异常，表示用户校验通过；如果发生异常，则表示校验未通过。
根据抛出的异常，还可以进一步得到校验未通过的原因，并且可以将异常的详细信息反馈给用户或记入日志。
这样的设计不但可以带来更好的用户体验，而且极大地方便了以后程序的调试和维护。
一个异常包含的信息远远比一个简单的返回值丰富的多。
2.3.3工具类
工具类用来提供一组通用的公共方法。
工具类应该设计成为拥有一组静态的工具方法，因而不需要实例化就可以使用；工具类可以有一组静态终态（staticfinal）字段表示通用常量，但是不应有任何非静态字段；工具类应该声明一个私有的缺省构造函数或者直接声明成抽象的，以防止被继承或被实例化。
2.3.4System.out和System.err
不要滥用System.out和System.err。
在编写程序、单元测试和后期调试的时候，很多人喜欢直接或间接地使用System.out和System.err打印调试信息。
当程序最终发布的时候，如果忘了删除这些调试信息，会造成很多“垃圾”输出，严重的时候，这些“垃圾”输出会导致日志文件迅速挤满硬盘。
建议使用java.util.logging或其他一些第三方的工具包来打印调试信息，而不要直接使用System.out或System.err。
当然，也可以自行编写一个简单的Debug工具类实现调试信息的输出。
这样，当程序发布时，只需要进行简单的修改或配置，就可以除去所有的调试信息。
2.3.5静态方法
静态方法一定要静态调用，而不要使用实例。
例如要挂起当前线程，应该调用“Thread.sleep（1000）;”
而不是“Thread.currentThread（）.sleep（1000）;”。
2.3.6StringBuffer
在对字符串进行较多的拼接、拆分工作时，应尽量使用StringBuffer，StringBuilder对象，而不是直接对String对象操作。
2.3.7代码复用
不要使用过多的“复制”、“粘贴”实现代码的复用。
如果一段代码被复制、粘贴了超过3次，就应该考虑将这段代码重新封装到一个方法中。
如果出现第4个地方需要使用这段代码，并且需要对代码作稍许改动，则应该考虑将刚才封装的方法进行改造而不是重新定义一个方法。
2.3.8垃圾回收
不要迷信垃圾回收。
垃圾回收调用的时间是不可预知的，因此一般不要依赖垃圾回收机制使用finalize方法来做清理工作。
如果想及时回收还是自己亲自写回收方法并且显示调用。
升级会员 