JAVA编程规范.docx

JAVA编程规范.docx

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

JAVA编程规范

JAVA编程规范

JavaCodingConventions

（V1.0）

编制单位：

xxxx有限公司

项目名称：

xxxxx系统

项目代号：

xxx_ZYZQ

文档名称：

JAVA软件编程规范

文档作者:

xxxx

文档审核：

xxx

编制日期：

20xx-05-29

修订纪录：

日期

变动记录

编写

审核

20xx-05-29

初稿

xxx

xxxx

目录

一、命名4

1、字符集4

2、Package的命名4

3、Class的命名4

4、变量的命名4

5、Static、Final变量的命名4

6、参数的命名4

7、数组的命名5

8、方法的命名5

二、注释5

1、文档化5

2、使用中文5

3、版权信息5

4、Class6

5、ClassFields6

6、方法6

7、典型算法、过程6

三、风格7

1、Package/Imports7

2、缩进7

3、页宽7

4、{}对7

5、括号8

6、换行8

7、续行8

8、运算符之间的间隔9

四、程序编写规范9

1、类的组织形式9

2、方法（函数）9

3、变量10

4、基本数据类型10

5、条件语句11

6、循环语句11

7、循环变量11

8、禁止使用goto语句11

9、重载11

10、main方法11

11、资源的释放12

12、其它12

五、类设计原则12

六、调试14

七、性能15

八、开发系统维护15

1、专人负责15

2、VSS15

3、系统维护16

一、命名

1、字符集

对于所有标识符使用的有效字符集都必须是：

‘a’--‘z’，‘A’--‘Z’，‘0’--‘9’，‘_’。

并且所有命名应以字母开头。

2、Package的命名

Package的名字应该都是由一个小写单词组成。

3、Class的命名

Class的名字必须由大写字母开头，后面的单词用大写字母开头。

例如：

publicclassWhiteHorse{

}

4、变量的命名

变量的名字必须用一个小写字母开头，后面的单词用大写字母开头，变量中不可出现’_’字符。

例如：

privatestaticfloatsumDiffSquares=0;

相反：

privatestaticfloatSum=0;

privatestaticfloatsumdiffsquares=0;

privatestaticfloatsum_diff_squares=0;

privatestaticfloatx=0;

5、Static、Final变量的命名

Static、Final变量的名字应该都大写，并且指出完整含义。

不同单词之间用“_”隔开。

6、参数的命名

参数的名字必须和变量的命名规范一致。

使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：

publicvoidsetCounter（intsize）{

this.size=size;

}

7、数组的命名

数组应该总是用下面的方式来命名：

byte[]buffer;

而不是：

bytebuffer[];

8、方法的命名

和变量的命名规范一致。

二、注释

1、文档化

a.必须用javadoc来为类生成文档。

不仅因为它是标准，这也是被各种java编译器都认可的方法。

b.注释行于相应的代码同样缩排。

c.每行只定义一个数据，便于在其后加注释。

d.注释行与程序行在同一行时，应注意上下注释行对齐。

e.注意：

注释中换行时要用
，不能用。

因为

2、使用中文

除规定的、约定俗成的注释使用英文之外，其他注释一律使用中文。

3、版权信息

版权信息必须在java文件的开头，比如：

/**

*Copyright®2000ShanghaiXXXCo.Ltd.

*Allrightreserved.

*/

其他不需要出现在javadoc的信息也可以包含在这里。

4、Class

接下来的是类的注释，一般是用来解释类的，必须有。

/**

*<类名定义>奔驰车模型

*<类的设计目的、思想>此类是为国际汽车评展会期间的进行各类汽车的比较

*而设计的模型，需要重点突出各类汽车的优势与风格。

*<类的简要功能说明>此类通过继承普通汽车实现了汽车的一般特征与行为，

*并且定义了奔驰车所特有的属性，如车载GPS，还展示了奔驰车与众不同的

*冰面行驶、沙漠越野效果等。

*/

publicclassBensextendsCar

5、ClassFields

接下来是类的成员变量：

/**

*汽车发动机

*在实例化汽车时会实现此发动机。

*/

protectedEngineengine;

public的成员变量必须生成文档（JavaDoc）。

proceted、private和package定义的成员变量如果名字含义明确的话，可以没有注释。

6、方法

public方法必须生成文档。

每个方法必须有符合统一格式的函数说明

/**

*<函数名>冰面行使

*<功能>展示了奔驰车以各种速度在冰面上的行使状况。

*@paramdoublespeed汽车速度（公里/小时）

*@see

*@return

*@exceptionCarException

*/

publicvoidrunOnGlacier（doublespeed）throwsCarException

7、典型算法、过程

在典型算法或过程前都应有注释。

三、风格

1、Package/Imports

package行要在import行之前，import中标准的包名要在本地的包名之前，而且按照字母顺序排列。

尽量明确import的类名，避免在import行中出现“*”。

package.stats;

importjava.util.ArrayList;

importjava.util.Observable;

importhotlava.util.Application;

2、缩进

缩进应该是每行4个空格，不要在源文件中保存Tab字符，因为在使用不同的源代码管理工具时Tab字符将因为用户设置的不同而扩展为不同的宽度。

如果你使用UltrEdit作为你的Java源代码编辑器的话，你可以通过如下操作来禁止保存Tab字符,方法是通过UltrEdit中先设定Tab使用的长度室4个空格，然后用Format|TabstoSpaces菜单将Tab转换为空格。

3、页宽

页宽应该设置为80字符。

源代码一般不会超过这个宽度，并导致无法完整显示，但这一设置也可以灵活调整。

在任何情况下，超长的语句应该在一个逗号或者一个操作符后折行。

一条语句折行后，应该比原来的语句再缩进4个字符。

4、{}对

{}中的语句应该单独作为一行，例如：

if（i>0）{

i++

};//正确,{单独作为一行

if（i>0）{i++};//错误,{和}在同一行

if（i>0）//不采用,

{

i++;

}

}语句应该缩进到与其相对应的{那一行相对齐的位置。

5、括号

左括号和后一个字符之间不应该出现空格，同样，右括号和前一个字符之间也不应该出现空格。

下面的例子说明括号和空格的错误及正确使用：

call（parameter）;//错误

call（parameter）;//正确

不要在语句中使用无意义的括号。

括号只应该为达到某种目的而出现在源代码中。

下面的例子说明错误和正确的用法：

if（（I）=42）{//错误-括号毫无意义

if（I==42）or（J==42）then//正确-的确需要括号

6、换行

两个方法之间应间隔2行。

例如：

publicstaticvoidmain（String[]arg）

{

System.out.println（"Hello"+""+"World"）;

}

publicvoidfoo（）

{

//Somecodehere

}

7、续行

a.表达式换行，以运算符结尾。

Stringsql=“SELECTname,age”+

“FROMtable”+

“WHEREgrade=‘6’”;

b.逻辑判断表达式，以逻辑运算符开始。

if（isThisYear（）

&&isThisMonth（）

&&isThisDate（））{

}

c.控制语句续行应该缩排标准格数

while（PathName[StartPath+Pos]!

=‘;’）

&&（（StartPath+Pos）<=length（PathName））

d.赋值语句续行写在赋值号之后

TotalCustomerBill=CustomerBill+LateCharge（CustomerID）+

PreviousBalance（CustomerID）;

8、运算符之间的间隔

两个运算符之间应间隔一个空格。

例如：

publicstaticvoidmain（String[]arg）

{

System.out.println（"Hello"+""+"World"）;

}

相反：

publicstaticvoidmain（String[]arg）

{

System.out.println（"Hello"+""+"World"）;

}

四、程序编写规范

1、类的组织形式

a.每个公共的类应该放在一个单独的文件里。

b.尽量不与已存在类的名字相同，以免引起混淆。

c.对于类的属性，应按public、protected、packagelevel、private顺序定义。

d.对于类的方法，应按public、protected、packagelevel、private顺序定义。

e.避免一个类的代码超过2000行。

2、方法（函数）

a.函数功能单一

每个函数的功能尽量单一；非常复杂的功能应适当才分为多个函数实现。

每个函数只有一个出口。

b.函数的长度

对于函数的长度不作硬性规定，建议长度不超过100行（不包括注释行和空行），但是不允许出现大于300行的函数。

c.方法参数检查

函数应检查所有输入的参数值，确数值在允许范围之内；要在代码中注释出输入数据的允许范围。

d.异常情况处理

对于出现的意外情况，应该能够产生一个警告，提示出现了另外一种情况。

例如switch（）语句应包含一个default分支来处理意外条件，等等。

e.检查函数返回值

对于有返回值的函数，在调用时应注意检查返回值。

对于过程性函数，建议也写成带有返回值的函数，以逻辑型返回值表示过程执行是否成功（成功返回TRUE，失败返回FALSE）。

没有明确返回值的函数一定要用void说明。

f.函数参数

a）按照输入—修改—输出的顺序排列参数

b）如果几个函数中使用了相似的参数，应尽量按照一致的顺序排列这些参数

c）不要把函数中的参数当作工作变量，应该使用局部变量来替代它

d）把函数的参数个数限制在7个以下。

3、变量

a.同一变量的含义应保持单一性，不宜使用同一变量代表多种含义。

例如局部变量count仅用于控制计数。

b.建立所有全局变量的注释表（数据字典）

4、基本数据类型

a.常数

a）使用命名常量或全局变量来替代常数，程序中不得出现直接常量

b）采取预防被“0”除的措施

b.整型数

a）检查整型相除

b）检查整型是否溢出

c）检查中间结果是否溢出

c.浮点数

a）不要在数量级相差太大的数之间进行加减运算

b）避免相等比较，可以先确定一个可以接受的精度范围，然后用逻辑函数来确定两个数是否接近

c）防止舍入误差

d.字符和字符串

a）使用命名常量或全局变量来替代字符或字符串常数，程序中不得出现直接字符或字符串常量

b）警惕边界错误

e.数组

a）确保所有数组下标没有越界

b）对于多维数组，警惕下标的错误交叉

c）使数组的长度留有一定富余量

5、条件语句

a.if语句

a）把正常情况放在if后面而不是else后面

b）最常见的情况放在最开始

c）if语句与else语句最好同时使用

b.case语句

a）把各种情况按字母或数字顺序组织

b）把正常情况的事件放在最开始

c）把经常执行的情况放在最开始

d）用缺省语句检查错误，不要使用它作为一种情况

e）注意每个情况对应的代码都应当有一个结束语句

6、循环语句

a.确保循环能终止

b.检查循环边界

c.尽量使用有意义的变量名以避免循环变量使用错误

d.尽量使循环在一页内显示完，嵌套层数不超过5层

e.对于无条件循环，使用while（true）

7、循环变量

a.简单的循环控制变量可以使用：

i，j，k

b.如果循环变量还要在循环外使用，应该使用能够说明问题的名称

c.如果循环体较长，最好使用有意义的名字

d.对于一个多重嵌套的循环，最好以较长的名字改善其可读性

8、禁止使用goto语句

9、重载

它们应该用递增的方式写（比如：

参数多的写在后面）。

publicvoidexecute（intsize）;

publicvoidexecute（intsize,inthight）;

publicvoidexecute（intsize,inthight,intwidth）;

10、main方法

如果定义main（String[]）方法,那么它应该写在类的底部。

11、资源的释放

要注意资源的释放。

比如：

文件、JDBC的Connection等。

12、其它

a.不允许忽视编译中的警告错误

b.常用函数应先查询公共库，尽量避免冗余代码；使用频繁的函数应申请加入公共函数库（public）

c.在做任何修改之前一定要备份

d.禁止把目标码和执行码放在源码目录下

e.无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查

f.改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响

五、类设计原则

1.为了常规用途而创建一个类时，请采取“经典形式”，并包含对下述元素的定义：

equals（） 

hashCode（） 

toString（） 

clone（）（implement Cloneable） 

implement Serializable

2.应将方法设计成简要的、功能性单元，用它描述和实现一个不连续的类接口部分。

理想情况下，方法应简明扼要。

若长度很大，可考虑通过某种方式将其分割成较短的几个方法。

这样做也便于类内代码的重复使用（有些时候，方法必须非常大，但它们仍应只做同样的一件事情）。

3.设计一个类时，请设身处地为客户程序员考虑一下（类的使用方法应该是非常明确的）。

然后，再设身处地为管理代码的人考虑一下（预计有可能进行哪些形式的修改，想想用什么方法可把它们变得更简单）。

4.使类尽可能短小精悍，而且只解决一个特定的问题。

下面是对类设计的一些建议：

■一个复杂的开关语句：

考虑采用“多形”机制 

■数量众多的方法涉及到类型差别极大的操作：

考虑用几个类来分别实现 

■许多成员变量在特征上有很大的差别：

考虑使用几个类 

5.让一切东西都尽可能地“私有”——private。

在多线程环境中，隐私是特别重要的一个因素——只有private字段才能在非同步使用的情况下受到保护。

6.谨惕“巨大对象综合症”。

对一些习惯于顺序编程思维、且初涉OOP领域的新手，往往喜欢先写一个顺序执行的程序，再把它嵌入一个或两个巨大的对象里。

根据编程原理，对象表达的应该是应用程序的概念，而非应用程序本身。

7.若不得已进行一些不太雅观的编程，至少应该把那些代码置于一个类的内部。

8.任何时候只要发现类与类之间结合得非常紧密，就需要考虑是否采用内部类，从而改善编码及维护工作。

9.避免使用“魔术数字”，这些数字很难与代码很好地配合。

如以后需要修改它，无疑会成为一场噩梦，因为根本不知道“100”到底是指“数组大小”还是“其他全然不同的东西”。

所以，我们应创建一个常数，并为其使用具有说服力的描述性名称，并在整个程序中都采用常数标识符。

这样可使程序更易理解以及更易维护。

10.涉及构建器和异常的时候，通常希望重新丢弃在构建器中捕获的任何异常——如果它造成了那个对象的创建失败。

这样一来，调用者就不会以为那个对象已正确地创建，从而盲目地继续。

11.当客户程序员用完对象以后，若你的类要求进行任何清除工作，可考虑将清除代码置于一个良好定义的方法里，采用类似于cleanup（）这样的名字，明确表明自己的用途。

除此以外，可在类内放置一个boolean（布尔）标记，指出对象是否已被清除。

在类的finalize（）方法里，请确定对象已被清除，并已丢弃了从RuntimeException继承的一个类（如果还没有的话），从而指出一个编程错误。

在采取象这样的方案之前，请确定finalize（）能够在自己的系统中工作（可能需要调用System.runFinalizersOnExit（true），从而确保这一行为）。

12.在一个特定的作用域内，若一个对象必须清除（非由垃圾收集机制处理），请采用下述方法：

初始化对象；若成功，则立即进入一个含有finally从句的try块，开始清除工作。

13.若在初始化过程中需要覆盖（取消）finalize（），请记住调用super.finalize（）（若Object属于我们的直接超类，则无此必要）。

在对finalize（）进行覆盖的过程中，对super.finalize（）的调用应属于最后一个行动，而不应是第一个行动，这样可确保在需要基础类组件的时候它们依然有效。

14.创建大小固定的对象集合时，请将它们传输至一个数组（若准备从一个方法里返回这个集合，更应如此操作）。

这样一来，我们就可享受到数组在编译期进行类型检查的好处。

此外，为使用它们，数组的接收者也许并不需要将对象“造型”到数组里。

15.尽量使用interfaces，不要使用abstract类。

若已知某样东西准备成为一个基础类，那么第一个选择应是将其变成一个interface（接口）。

只有在不得不使用方法定义或者成员变量的时候，才需要将其变成一个abstract（抽象）类。

接口主要描述了客户希望做什么事情，而一个类则致力于（或允许）具体的实施细节。

16.在构建器内部，只进行那些将对象设为正确状态所需的工作。

尽可能地避免调用其他方法，因为那些方法可能被其他人覆盖或取消，从而在构建过程中产生不可预知的结果。

17.对象不应只是简单地容纳一些数据；它们的行为也应得到良好的定义。

18.在现成类的基础上创建新类时，请首先选择“新建”或“创作”。

只有自己的设计要求必须继承时，才应考虑这方面的问题。

若在本来允许新建的场合使用了继承，则整个设计会变得没有必要地复杂。

19.用继承及方法覆盖来表示行为间的差异，而用字段表示状态间的区别。

一个非常极端的例子是通过对不同类的继承来表示颜色，这是绝对应该避免的：

应直接使用一个“颜色”字段。

20.为避免编程时遇到麻烦，请保证在自己类路径指到的任何地方，每个名字都仅对应一个类。

否则，编译器可能先找到同名的另一个类，并报告出错消息。

若怀疑自己碰到了类路径问题，请试试在类路径的每一个起点，搜索一下同名的.class文件。

21.用合理的设计方案消除“伪功能”。

也就是说，假若只需要创建类的一个对象，就不要提前限制自己使用应用程序，并加上一条“只生成其中一个”注释。

请考虑将其封装成一个“独生子”的形式。

若在主程序里有大量散乱的代码，用于创建自己的对象，请考虑采纳一种创造性的方案，将些代码封装起来。

22.警惕“分析瘫痪”。

请记住，无论如何都要提前了解整个项目的状况，再去考察其中的细节。

由于把握了全局，可快速认识自己未知的一些因素，防止在考察细节的时候陷入“死逻辑”中。

23.警惕“过早优化”。

首先让它运行起来，再考虑变得更快——但只有在自己必须这样做、而且经证实在某部分代码中的确存在一个性能瓶颈的时候，才应进行优化。

除非用专门的工具分析瓶颈，否则很有可能是在浪费自己的时间。

性能提升的隐含代价是自己的代码变得难于理解，而且难于维护。

24.请记住，阅读代码的时间比写代码的时间多得多。

思路清晰的设计可获得易于理解的程序，但注释、细致的解释以及一些示例往往具有不可估量的价值。

无论对你自己，还是对后来的人，它们都是相当重要的。

如对此仍有怀疑，那么请试想自己试图从联机Java文档里找出有用信息时碰到的挫折，这样或许能将你说服。

25.如认为自己已进行了良好的分析、设计或者实施，那么请稍微更换一下思维角度。

试试邀请一些外来人士——并不一定是专家，但可以是来自本公司其他部门的人。

请他们用完全新鲜的眼光考察你的工作，看看是否能找出你一度熟视无睹的问题。

采取这种方式，往往能在最适合修改的阶段找出一些关键性的问题，避免产品发行后再解决问题而造成的金钱及精力方面的损失。

26.良好的设计能带来最大的回报。

简言之，对于一个特定的问题，通常会花较长的时间才能找到一种最恰当的解决方案。

但一旦找到了正确的方法，以后的工作就轻松多了，再也不用经历数小时、数天或者数月的痛苦挣扎。

我们的努力工作会带来最大的回报（甚至无可估量）。

而且由于自己倾注了大量心血，最终获得一个出色的设计方案，成功的快感也是令人心动的。

坚持抵制草草完工的诱惑——那样做往往得不偿失。

27.程序首先是正确，其次是优美。

28.可读性第一，效率第二。

重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。

29.公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。

30.不要随意定义全局变量，尽量使用局部变量。

绝对不要因为性能的原因将类定义为final的（除非程序的框架要求）

31.如果一个类还没有准备好被继承，最好在类文档中注明，而不要将她定义为final的。

这是因为没有人可以保证会不会由于什么原因需要继承她。

32.exit除了在main中可以被调用外，其他的地方不应该调用。

因为这样做不给任何代码代码机会来截获退出。

一个类似后台服务地程序不应该因为某一个库模块决定了要退出就退出。

33.申明的错误应该