JAVA编码规范3.docx
《JAVA编码规范3.docx》由会员分享，可在线阅读，更多相关《JAVA编码规范3.docx（13页珍藏版）》请在冰点文库上搜索。
JAVA编码规范3
1.命名规范
命名要使用具有实际意义的英文单词，或者单词的缩写，不要使用单个的字母来命名一个变量，一个好的命名，几乎不用看文档就能知道该方法或者变量的意义，如同JavaAPI，它的命名还是很值得借鉴的。
命名的一般规范：
1.尽量使用完整的英文描述符（除非特别必要，尽量不要使用汉语拼音缩写形式）。
2.采用适用于相关领域的术语（如url之类的术语，但术语必须是大家认可的）。
3.采用大小写混合使名字可读。
4.尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一，一些常用的缩写可以参考JavaAPI如message的缩写可以为msg。
5.避免使用长的名字（小于15个字母是个好主意）。
6.避免使用类似的名字，或者仅仅是大小写不同的名字。
7.避免使用下划线（除静态常量等）。
1.1.package的命名
package的名字应该都是由小写字母单词组成,名字的前两级为com.highsoft，三级名称为模块名。
例如：
包名com.highsoft.demo.action表示demo模块下处理类包名。
1.2.Class的命名
Class的名字必须由大写字母开头而其他字母都小写的单词组成，对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。
例如：
publicclassThisAClassName{}
1.3.变量的命名
对于变量的命名，要尽量达到能通过变量名知道这个变量表达的含义，变量采用小写字母开头，对于由多个单词组成的变量名，所有单词都应紧靠在一起，而且大写中间单词的首字母。
对于常量（staticfinal类型）采用如下方式命名：
字母全部大写并使用下划线分隔单词（如：
DB_CONFIG）。
1.4.参数的命名
参数的名字必须和变量的命名规范一致。
1.5.数组的命名
数组命名和变量命名类似，主要是能体现出这是一组数据。
1.6.方法的参数
使用有意义的参数命名。
同时请参照“变量的命名”条目。
对于javabean中简单的set和get方法，可以使用和要赋值的字段一样的名字。
setSize（intsize）{
this.size=size;
}
1.7.方法的命名
方法的命名遵循变量的命名，方法的名字必须用一个小写字母开头。
后面的单词用大写字母开头。
1.8.特定类的命名
对于Servlet类，在对象后加后缀Servlet来命名，如：
UserServlet。
对于Applet类，在对象后加后缀Applet来命名，如：
GraphApplet。
对于JUnit和测试类，在对象后加后缀Test来命名，如UserTest。
其他的特定类命名以后将不断补充进本标准中。
2.注释规范
2.1.使用代码注释的目的和关键
1.文字说明代码的作用（即为什么要用编写该代码，而不是如何编写）；
2.明确指出该代码的编写思路和逻辑方法；
3.使阅读者注意到代码中的重要转折点；
4.使阅读者不必在他们的头脑中仿真运行代码的执行方法。
5.何时书写注释：
1）请在每个if语句的前面加上注释；2）在每个switch语句的前面加上注释。
与if语句一样，switch语句用于评估对程序执行产生影响的表达式。
3）在每个循环的前面加上注释。
每个循环都有它的作用，许多情况下这个作用不清楚直观。
2.2.Java的注释
单行注释：
//注释一行
多行注释：
/*......*/注释若干行
文档注释：
/**......*/注释若干行，并写入javadoc文档，对共有变量、方法，使用该种注释。
说明：
提供给客户程序员使用的接口、公用类要严格按照文档注释进行注释，并生成doc文档，做到客户程序员通过阅读doc来使用共有类，而不是阅读源代码来使用一个公共接口或者类。
●边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
●注释要简单明了。
●要区分两种注释的区别，一种是文档注释，是给客户程序员使用的，他们不会阅读你的源代码，因此要尽可能的提供更多的信息，让他们使用起来方便；另一种是非文档注释，是提供给代码的维护人看的，是为了给代码的维护人员看的，他们是要看到你的源代码的，因此非文档注释要简单明了。
下面是一个公用类的注释：
packagejava.blah;
importjava.blah.blahdy.BlahBlah;
/**
*对类的用途的描述.
*
*@version1.821999-03-18（版本信息，变更关键字），加上版本作者
1.821999-09-23
*@authorFirstnameLastname（作者信息）
*/
publicclassMyClassextendsSomeClass{
/**对公有成员变量的注释（单行的格式），建议采用单行的格式，节省版面*/
publicintclassVar1;
/**
*对共有成员变量的注释（多行的格式）
*morethanonelinelong
*/
privateObjectclassVar2;
/**
*...对该方法用途的描述
*@paramuserName对参数userName的描述
*@parampassword对参数password的描述
*@exception对抛出异常的说明
*@returnString对返回值的描述
*/
publicStringclassMethod（StringuserName,Stringpassword）{
//对代码片断的注释（如，以下用于密码验证）
if（flag==true）{
//对代码逻辑块进行注释（如：
如果密码验证通过）
}else{
//对代码逻辑块进行注释（如：
如果密码验证未通过）
}
}
}
2.3.JSP中注释
＜%--comment--%＞JSP注释，也称为“隐藏注释”。
JSP引擎将忽略它。
标记内的所有JSP脚本元素、指令和动作都将不起作用。
这种注释不会出现载JSP编译后的JSP页面中，建议使用。
＜!
--comment--＞HTML注释，也称为“输出的注释”，直接出现在结果HTML文档中。
标记内的所有JSP脚本元素、指令和动作正常执行。
2.4.使用javadoc注释
在自定义类中必须使用javadoc注释以保证客户程序员通过使用java自动编译生成的doc文档就能够使用你的类。
这里的注释请通过eclipse开发工具辅助生成，对参数、返回值等要做必要的说明。
2.5.变更注释
为了方便的让代码维护者看到文件的变更信息及历史，对于重要的修改请使用变更注释。
在javadoc的@version条目下请标明版本信息、修改日期、修改关键字和简单的修改说明信息。
在修改代码的开始和结束处使用修改标识和关键字进行标示。
注释时尽量不要删除变更前代码。
同时保证其他人员可以使用变更关键字来查找变更位置（后起的关键字必须保证和前面的关键字不重复并尽量保证非类似）。
举例如下：
//变更修改注释：
变更关键字：
modify。
张三（2006-04-26）。
因为错误进行了变更修改。
/*首先注释修改前的代码*/
开始进行变更修改
//变更修改完毕。
变更关键字：
modify
3.代码编写格式
3.1.缩进4个空格
缩进应该是每行4个空格。
尽量不要在源文件中保存Tab字符。
在使用不同的源代码管理工具时Tab字符将因为用户设置的不同而扩展为不同的宽度。
3.2.页宽为80字符
页宽应该设置为80字符。
源代码超过这个宽度可能导致无法完整显示，但这一设置也可以灵活调整。
在任何情况下，超长的语句应该在一个逗号或者一个操作符后折行。
一条语句折行后，应该比原来的语句再缩进4个字符。
3.3.if-else语句块
if-else语句块的格式如下，else紧接着if的结束大括号。
if（……）{
……
}else{
……
}
即使if条件语句语句后面如果只有一行代码，最好也放在大括号中
如：
if（flag==true）{
flag==false;
}
Stringusername＝newString（）;
……
而非以下形式：
if（flag==true）
flag==false;
Stringusername＝newString（）;
……
3.4.try-catch语句块
try-catch语句块应遵循如下格式：
try{
……
}catch（Exceptionex）{
……
}finally{
……
}
3.5.方法与方法之间或者方法体内的逻辑块之间以空行分隔
方法与方法之间，或者一个方法体中的逻辑块之间用空行来分割，增强代码的可读性。
3.6.public方法和public变量要优先排列前面
变量的排列顺序：
首先是类的公共变量，随后是保护变量，再后是包一级别的变量（没有访问修饰符，accessmodifier），最后是私有变量
方法的排列顺序：
同变量的排列顺序。
这样使得首先看到得是类得公有变量和公有成员函数。
3.7.用三目运算符代替简单的if－else块
在判断关系简单并且稳定不变的地方使用可以增强代码可读性和提高性能。
3.8.运算符的排版格式
一元符与操作数之间不要空格，如i++，i--，i与++之间不要空格。
二元操作符与操作数之间要空格分开，如a=b+c;加号两端都加空格。
3.9.使用圆括号来避免运算符优先级问题
即使运算符的优先级对你而言可能很清楚，但对其他人未必如此。
你不能假设别的程序员和你一样清楚运算符的优先级。
应该在表达式中明确的制定优先级，避免难以理解的代码出现。
3.10.import使用规定
引入jdk及j2ee标准类时可以使用*，如importjava.io.*；
引入自定义类时，请一个类一条import语句，以增强代码可读性。
如importdfjh.basic.db.dbaccess；
4.Exception异常处理
通常的思想是只对错误采用异常处理：
逻辑和编程错误，设置错误，被破坏的数据，资源耗尽等。
通常的法则是系统在正常状态下以及无重载和硬件失效状态下，不应产生任何异常。
异常处理时可以采用适当的日志机制来报告异常，包括异常发生的时刻。
不要使用异常实现来控制程序流程结构。
4.1.分别捕获子类的异常而非父类Exception
比较合理的做法是分别捕获各个子类异常之后，分别处理不同的异常，不要一个方法内就一个try{}catch（）{}块。
4.2.使用Exception来返回异常，而非返回值
尽量使用Exception来反映函数运行中的异常，而不是使用返回值来反映，除非有充分理由这样做。
越是底层的类越应该使用Exception来反映函数运行中的异常。
4.3.禁止使用空的catch（）{}代码
绝对不允许代码中出现catch（）{}而什么也没做。
因为这样做还不如直接把异常抛出，让使用该方法的人来处理。
同时只要你catch了一个异常，JVM就认为你已经处理了该异常，其实你什么也没有做，这样就使很多的异常可能隐藏起来了。
4.4.Exception信息输出
在每一个catch到一个异常的时候，在调试状态下请使用ex.printStackTrace（）来输出错误信息；在运行状态下请使用ex.getMessege（）来输出错误信息。
通常情况下应该加上比较容易读懂的中文信息的输出。
5.性能优化（推荐标准）
5.1.避免不必要的对象构造
有的时候，构造了一个变量由于某种原因，您可能没有使用它，每构造一个对象可能会花销一定得CPU时间，正确的做法是先申明，到需要使用的时候才构造它的一个对象。
一般不要在申明时构造一个对象（尤其是针对类变量）。
5.2.不要在循环中构造和释放对象
不要象一下代码一样构造对象：
for（inti=0;i<50;i++）{
DoubledoubleObj=newDouble;
doubleObj=……；
}
而应该使用如下方法：
DoubledoubleObj=newDouble;
for（inti=0;i<50;i++）{
doubleObj=……；
}
5.3.使用StringBuffer对象
在处理String的时候要尽量使用StringBuffer类，StringBuffer类是构成String类的基础。
String类将StringBuffer类封装了起来，（以花费更多时间为代价）为开发人员提供了一个安全的接口。
当我们在构造字符串的时候，我们应该用StringBuffer来实现大部分的工作，当工作完成后将StringBuffer对象再转换为需要的String对象。
比如：
如果有一个字符串必须不断地在其后添加许多字符来完成构造，那么我们应该使用StringBuffer对象和它的append（）方法。
如果我们用String对象代替StringBuffer对象的话，会花费许多不必要的创建和释放对象的CPU时间。
例如：
常用的是定义SQL语句时，你可能会用到过+=来扩充SQL语句的内容，由于String对象是长度不能改变的，其实使用+=是每次构造一个新的String对象。
该字符串的内容是原来字符串内容与新加入的内容之和,再把新字符串赋值给原来的字符串变量。
比较合理的做法是使用StringBuffer类来代替String。
StringBufferstringBuffer=newStringBuffer（"初始内容"）;
StringBuffer.append（"＋加上新的内容"）;
StringBuffer.toString（）;
StringBuffer的append还重载了许多实用方法，如append（intintValue）等等，支持基本数据类型的，省去了你再将基本数据类型转换为对应的String，再使用+=连接字符串的麻烦。
说明：
在字符串长度大于100时，必须使用本标准。
5.4.避免太多的使用synchronized关键字
避免不必要的使用关键字synchronized，应该在必要的时候再使用它。
5.5.不是必要的时候不要使用Vector、Hashtable等同步化的数据结构
这些数据结构是同步化的，会对性能造成一定的影响，因此，不是必要的时候不要使用，可以使用他们的替代品ArrayList和HashMap代替。
6.设计类和方法的原则
6.1.创建具有很强内聚力的类
方法的重要性往往比类的重要性更容易理解，方法是指执行一个统一函数的一段代码。
类常被错误的视为是一个仅仅用于存放方法的容器。
有些开发人员甚至把这种思路作了进一步的发挥，将他们的所有方法放入单个类之中。
之所以不能正确的认识类的功能，原因之一是类的实现实际上并不影响程序的执行。
当一个工程被编译时，如果所有方法都放在单个类中或者放在几十个类中，这没有任何关系。
虽然类的数量对代码的执行并无太大的影响，但是当创建便于调试和维护的代码时，类的数量有时会带来很大的影响。
类应该用来将相关的方法组织在一起。
当类包含一组紧密关联的方法时，该类可以说具有强大的内聚力。
当类包含许多互不相关的方法时，该类便具有较弱的内聚力。
应该努力创建内聚力比较强的类。
大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。
在这种情况下，可以为这些不合群的方法创建一个综合性收容类。
创建类时，应知道“模块化”这个术语的含义是什么。
类的基本目的是创建相当独立的程序单元。
6.2.创建松散连接和高度专用的方法
6.2.1.使所有方法都执行专门的任务
每个方法都应执行一项特定的任务，它应出色的完成这项任务。
应避免创建执行许多不同任务的方法。
创建专用方法有许多好处。
首先调试将变得更加容易。
6.2.2. 尽量使方法成为自成一体的独立方法
当一个方法依赖于其他方法的调用时，称为与其他方法紧密连接的方法。
紧密连接的方法会使调试和修改变得比较困难，因为它牵涉到更多的因素。
松散连接的方法优于紧密连接的方法，但你不可能使每个方法都成为独立的方法。
若要使方法具备较强的独立性，方法之一是尽量减少类变量。
创建方法时，设法将每个方法视为一个黑箱，其他例程不应要求了解该方法的内部工作情况，该方法也不应要求了解它外面的工程情况。
这就是为什么你的方法应依靠参数而不应依靠全局变量的原因。
创建专用方法时，请考虑下列指导原则：
1.将复杂进程放入专用方法。
如果应用程序使用复杂的数学公式，请考虑将每个公式放入它自己的方法中。
这样使用这些公式的其他方法就不包含用于该公式的实际代码。
这样也可以更容易发现与公式相关的问题。
2.将数据输入/输出（I/O）放入专用方法。
3.将专用方法中可能要修改的代码隔离。
如果你知道某个进程经常变更，请将这个多变的代码放入专用方法，以便以后可以更容易的进行修改，并减少无意中给其他进程带来问题的可能性。
4.将业务规则封装在专用方法中。
业务规则常属于要修改的代码类别，应与应用程序的其余部分隔开。
其他方法不应知道业务规则，只有要调用的方法才使用这些规则。
6.2.3. 设计类和方法时，要达到下列目的：
1.创建更加容易调试和维护的方法；
2.创建具有强大内聚力的类；
3.创建高度专用的方法；
4.创建松散连接的方法；
5.尽量使方法具有独立性；
6.提高方法的扇入性；
7.降低方法的扇出性。
升级会员 