java平台代码编写规范.docx

上传人:b****1 文档编号:1006552 上传时间:2023-04-30 格式:DOCX 页数:26 大小:30.48KB
下载 相关 举报
java平台代码编写规范.docx_第1页
第1页 / 共26页
java平台代码编写规范.docx_第2页
第2页 / 共26页
java平台代码编写规范.docx_第3页
第3页 / 共26页
java平台代码编写规范.docx_第4页
第4页 / 共26页
java平台代码编写规范.docx_第5页
第5页 / 共26页
java平台代码编写规范.docx_第6页
第6页 / 共26页
java平台代码编写规范.docx_第7页
第7页 / 共26页
java平台代码编写规范.docx_第8页
第8页 / 共26页
java平台代码编写规范.docx_第9页
第9页 / 共26页
java平台代码编写规范.docx_第10页
第10页 / 共26页
java平台代码编写规范.docx_第11页
第11页 / 共26页
java平台代码编写规范.docx_第12页
第12页 / 共26页
java平台代码编写规范.docx_第13页
第13页 / 共26页
java平台代码编写规范.docx_第14页
第14页 / 共26页
java平台代码编写规范.docx_第15页
第15页 / 共26页
java平台代码编写规范.docx_第16页
第16页 / 共26页
java平台代码编写规范.docx_第17页
第17页 / 共26页
java平台代码编写规范.docx_第18页
第18页 / 共26页
java平台代码编写规范.docx_第19页
第19页 / 共26页
java平台代码编写规范.docx_第20页
第20页 / 共26页
亲,该文档总共26页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

java平台代码编写规范.docx

《java平台代码编写规范.docx》由会员分享,可在线阅读,更多相关《java平台代码编写规范.docx(26页珍藏版)》请在冰点文库上搜索。

java平台代码编写规范.docx

java平台代码编写规范

 

代码编写规范

 

目录

1前言5

1.1编写目的5

2命名规范5

2.1Package的命名5

2.2Class的命名5

2.3Class变量的命名6

2.4接口的命名6

2.5参数的命名7

2.6数组的命名7

2.7方法的参数命名7

3注释规范7

3.1实现注释的格式(ImplementationCommentFormats)8

3.1.1块注释(BlockComments)8

3.1.2单行注释(Single-LineComments)8

3.1.3尾端注释(TrailingComments)9

3.1.4行末注释(End-Of-LineComments)9

4Java文件样式10

4.1版权信息10

4.2Package/Imports10

4.3Class11

4.4ClassFields11

4.5存取方法11

4.6构造函数12

4.7克隆方法12

4.8类方法13

4.9main方法14

5代码编写格式14

5.1代码样式14

5.2文档化14

5.3缩进14

5.4页宽14

5.5{}对14

5.6括号15

6JAVA编码规范15

6.1注意15

6.2异常处理16

6.3垃圾收集16

6.4Clone17

6.5final类17

6.6访问类的成员变量17

6.7编写类的公共问题18

7JSP编码规范19

8代码编译20

9匈牙利命名规则20

9.1数据类型缩写21

9.2SWING一些控件的缩写21

9.3SWT一些控件的缩写21

9.4方法22

10部分编程常用单词缩写22

11编程技巧24

11.1byte数组转换到characters24

11.2Utility类24

11.3初始化24

11.4枚举类型24

11.5byte[]中的值25

11.6String和StringBuffer25

12调试25

13性能25

1前言

1.1编写目的

1、采用J2EE框架,基于J2EE的JSP、Servlet的MVC模式。

采用Struts、Hibernate、Spring等框架

2、Web服务器采用Tomcat或JBOSS。

3、使用Eclipse、Dreamweaver相关开发工具。

4、J2SE采用JavaAWT、多线程、SWING、JDBC等相关技术。

本规范是本项目组开发人员必须遵循的,可供测试等其他人员参考,本规范只适合本项目组内部使用。

特别注意

1、所有需要等待的程序加上进度条;

2、所有的方法加上javadoc注释,重要变量和属性也加上注释说明;

3、代码必须进行格式化,以使代码可读性强;

2命名规范

定义命名规范的目的是让项目中所有的文档看起来都像一个人写的,增加可读性,减少项目组中因为换人而带来的损失(这些规范并不是一定要绝对遵守,但是一定要让程序有良好的可读性)。

2.1Package的命名

包名的后续部分根据不同机构、不同项目的命名规范而不尽相同,尽量清晰,易懂,容易理解。

2.2Class的命名

Class的名字必须由大写字母开头、而其他字母都小写的单词组成。

尽量使类名简洁而有含义。

使用完整单词,避免缩写词(除非该缩写词被更广泛使用,像URL,HTML)。

如:

classRaster、classImageSprite。

2.3Class变量的命名

除了变量名外,所有实例,包括类,类常量,均采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写。

变量名不应以下划线或美元符号开头,尽管这在语法上是允许的。

变量名应简洁而有含义。

变量名的选用应该易于记忆,即能够指出其用途。

尽量避免单个字符的变量名,除非是一次性的临时变量。

临时变量通常被取名为i,j,k,m和n,它们一般用于整型;c,d,e,它们一般用于字符型。

如charc、inti、floatmyWidth。

实例变量InstanceVariables)

大小写规则和变量名相似。

常量(Constants)类常量和ANSI常量的声明,应该全部大写,单词间用下划线隔开(尽量避免ANSI常量,容易引起错误)。

如:

staticfinalintMIN_WIDTH=4、staticfinalintMAX_WIDTH=999、staticfinalintGET_THE_CPU=1。

除了以下几个特例之外,命名时应始终采用完整的英文描述符。

此外,一般应采用小写字母,但类名、接口名以及任何非初始单词的第一个字母要大写。

1、尽量使用完整的英文描述符;

2、采用适用于相关领域的术语;

3、采用大小写混合使名字可读;

4、尽量少用缩写,但如果用了,要明智地使用,且在整个工程中统一;

5、避免使用长的名字(小于15个字母);

6、避免使用类似的名字,或者仅仅是大小写不同的名字;

7、避免使用下划线。

2.4接口的命名

大小写规则与类名相似,如:

interfaceRasterDelegate、interfaceStoring。

方法(Methods)名采用大小写混合的方式,第一个单词的首字母小写,其后单词的首字母大写。

如:

run()、runFast()、getBackground()。

2.5参数的命名

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

2.6数组的命名

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

byte[]buffer;

而不是:

bytebuffer[];

2.7方法的参数命名

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

SetCounter(intsize){

this.size=size;

}

3注释规范

一般情况下程序有两类注释:

实现注释(ImplementationComments)和文档注释(DocumentComments)。

实现注释是使用/*...*/和//界定的注释。

文档注释(被称为"doccomments")是Java独有的,并由/**...*/界定。

文档注释可以通过javadoc工具转换成HTML文件。

实现注释用以注释代码或者实现细节。

文档注释从实现自由(implementation-free)的角度描述代码的规范。

它可以被那些手头没有源码的开发人员读懂。

注释应被用来给出代码的总括,并提供代码自身没有提供的附加信息。

注释应该仅包含与阅读和理解程序有关的信息。

例如,相应的包如何被建立或位于哪个目录下之类的信息不应包括在注释中。

3.1实现注释的格式(ImplementationCommentFormats)

程序可以有4种实现注释的风格:

块(block)、单行(single-line)、尾端(trailing)和行末(end-of-line)。

3.1.1块注释(BlockComments)

块注释通常用于提供对文件、方法、数据结构和算法的描述。

块注释被置于每个文件的开始处以及每个方法之前。

它们也可以被用于其他地方,比如方法内部。

在功能和方法内部的块注释应该和它们所描述的代码具有一样的缩进格式。

块注释之首应该有一个空行,用于把块注释和代码分割开来,比如:

/*

*Hereisablockcomment.

*/

块注释可以以/*-开头,这样indent

(1)就可以将之识别为一个代码块的开始,而不会重排它。

/*-

*Hereisablockcommentwithsomeveryspecial

*formattingthatIwantindent

(1)toignore.

*

*one

*two

*three

*/

3.1.2单行注释(Single-LineComments)

短注释可以显示在一行内,并与其后的代码具有一样的缩进层级。

如果一个注释不能在一行内写完,就该采用块注释。

单行注释之前应该有一个空行。

以下是一个Java代码中单行注释的例子:

if(condition){

/*Handlethecondition.*/

...

}

3.1.3尾端注释(TrailingComments)

极短的注释可以与它们所要描述的代码位于同一行,但是应该有足够的空白来分开代码和注释。

若有多个短注释出现于大段代码中,它们应该具有相同的缩进。

以下是一个Java代码中尾端注释的例子:

if(a==2){

returnTRUE;/*specialcase*/

}else{

returnisPrime(a);/*worksonlyforodda*/

}

3.1.4行末注释(End-Of-LineComments)

注释界定符"//",可以注释掉整行或者一行中的一部分。

它一般不用于连续多行的注释文本;然而,它可以用来注释掉连续多行的代码段。

以下是所有三种风格的例子:

if(foo>1){

//Doadouble-flip.

...

}

else{

returnfalse;//Explainwhyhere.

}

//if(bar>1){

//

////Doatriple-flip.

//...

//}

//else{

//returnfalse;

//}

4Java文件样式

注:

如果用ezStudio,可以导入我们组约定的代码模板文件后,就自动定义好了文件样式!

所有的Java(*.java)文件都必须遵守如下的样式规则。

4.1版权信息

版权信息必须在java文件的开头,比如:

/*

*/

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

4.2Package/Imports

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

packagecom.thtf.ezone.……;

importjava.util.Observable;

importhotlava.util.Application;

4.3Class

接下来的是类的注释,一般是用来解释类的。

/**

*

描述:

Jpc服务的用户接口类,调用了JpcService类的实现。

*

*@author作者姓名

*@version3.1

*/

接下来是类定义,包含了在不同的行的extends和implements。

publicclassCounterSet

extendsObservable

implementsCloneable

4.4ClassFields

接下来是类的成员变量:

/**

*Packetcounters

*/

protectedint[]packets;

public的成员变量必须生成文档(JavaDoc)。

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

4.5存取方法

接下来是类变量的存取的方法。

它只是简单的用来将类的变量赋值获取值的话,可以简单的写在一行上。

如类的成员变量已经有注释,类变量的存取方法可以没有注释。

/**

*功能说明:

*@paramopcData要设置的Opc数据

*@returntrue成功false失败

*@throwsServiceUnavailableException服务不可用异常

*/

publicstaticbooleansetDataToOpc(OpcDataopcData)throwsServiceUnavailableException{

returntrue;

}

publicint[]getPackets(Strings){returncopyArray(packets,offset);}

publicint[]getBytes(){returncopyArray(bytes,offset);}

publicint[]getPackets(){returnpackets;}

publicvoidsetPackets(int[]packets){this.packets=packets;}

要求说明的是,对于集合,加入成员函数来插入和删除项;另其它的方法不要写在一行上。

4.6构造函数

接下来是构造函数,它应该用递增的方式写(比如:

参数多的写在后面)。

访问类型(“"public”,“private”等)和任何“static”,“final”或“synchronized”应该在一行中,并且方法和参数另写一行,这样可以使方法和参数更易读。

public

CounterSet(intsize){

this.size=size;

}

4.7克隆方法

如果这个类是可以被克隆的,那么下一步就是clone方法:

public

Objectclone(){

try{

CounterSetobj=(CounterSet)super.clone();

obj.packets=(int[])packets.clone();

obj.size=size;

returnobj;

}catch(CloneNotSupportedExceptione){

thrownewInternalError("UnexpectedCloneNotSUpportedException:

"+e.getMessage());

}

}

4.8类方法

下面开始写类的方法:

/**

*Setthepacketcounters

*(suchaswhenrestoringfromadatabase)

*/

protectedfinal

voidsetArray(int[]r1,int[]r2,int[]r3,int[]r4)

throwsIllegalArgumentException

{

//

//Ensurethearraysareofequalsize

//

if(r1.length!

=r2.length||r1.length!

=r3.length||r1.length!

=r4.length)

thrownewIllegalArgumentException("Arraysmustbeofthesamesize");

System.arraycopy(r1,0,r3,0,r1.length);

System.arraycopy(r2,0,r4,0,r1.length);

}

4.9main方法

如果main(String[])方法已经定义了,那么它应该写在类的底部。

5代码编写格式

5.1代码样式

代码应该用unix的格式,而不是windows的(比如:

回车变成回车+换行)。

5.2文档化

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

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

5.3缩进

缩进应该是每行2个空格。

不要在源文件中保存Tab字符,在使用不同的源代码管理工具时,Tab字符将因为用户设置的不同而扩展为不同的宽度。

5.4页宽

页宽应该设置为80字符。

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

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

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

5.5{}对

{}中的语句应该单独作为一行。

例如,下面的第1行是错误的,第2行是正确的:

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

if(i>0){

i++

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

}语句永远单独作为一行

5.6括号

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

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

CallProc(AParameter);//错误

CallProc(AParameter);//正确

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

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

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

if((I)=42){//错误-括号毫无意义

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

6JAVA编码规范

6.1注意

1、每个类不能长于500行,一个方法的长度尽量控制在50行内;

2、每个类、每个方法都必须都有注释,在一个方法内长于10行必须要有注释;

3、一个方法只能有一项明确的责任;

4、让一切东西都尽可能地“私有”——private,除非有特别好的理由,不要把任何类变量或实例变量公众化(public)。

我们规定,实例变量是不需要显式的设置或获取的,统一设成私有的,要取则必须通过某种方法来完成。

5、尽量使用interfaces,不要使用abstract类。

6、避免代码重复。

7、import类时不要使用通配符,如importjava.awt.*,要把每一个用到的类单独列出,没有用到的一定要去除。

8、exit除了在main中可以被调用外,其他的地方不应该调用。

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

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

6.2异常处理

申明的错误应该抛出一个RuntimeException或者派生的异常。

顶层的main()函数应该截获所有的异常,并且打印(或者记录在日志中)在屏幕上。

异常处理要根据类型进行编码,如“ezStudio3-0001”

在错误输出时采用错误编码+提示信息的方式,如:

"ezStudio3-0001:

文件打开失败",其中提示信息从resourceBundle中读出。

错误的输出采用Log4j来实现。

即输出时不要采用System.out.println("ezStudio30001:

打开文件失败")的方式,而要用logger.warn("ezIBS0001:

打开文件失败")的方式。

Log4j的学习参见(http:

//hedong.3322.org/archives/000193.html)。

6.3垃圾收集

JAVA使用成熟的后台垃圾收集技术来代替引用计数。

但是这样会导致一个问题:

必须在使用完对象的实例以后进行清场工作。

我建议大家能尽可能地由我们自己手工清除垃圾,收集内存。

除非输出流一出作用域就关闭,非引用计数的程序语言,比如JAVA,是不能自动完成变量的清场工作的。

必须象下面一样写:

FileOutputStreamfos=newFileOutputStream(projectFile);

project.save(fos,"IDEProjectFile");

fos.close();

6.4Clone

下面是一种有用的方法:

implementsCloneable

public

Objectclone()

{

try{

ThisClassobj=(ThisClass)super.clone();

obj.field1=(int[])field1.clone();

obj.field2=field2;

returnobj;

}catch(CloneNotSupportedExceptione){

thrownewInternalError("UnexpectedCloneNotSUpportedException:

"+e.getMessage());

}

}

6.5final类

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

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

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

6.6访问类的成员变量

大部分的类成员变量应该定义为protected的来防止继承类使用他们。

注意,要用"int[]packets",而不是"intpackets[]",后一种永远也不要用。

publicvoidsetPackets(int[]packets){this.packets=packets;}

CounterSet(intsize)

{

this.size=size;

}

6.7编写类的公共问题

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

equals()

hashCode()

toString()

clone()(implementCloneable)

implementSerializable

2、对于自己创建的每一个类,都考虑置入一个main(),其中包含了用于测试那个类的代码。

为使用一个项目中的类,我们没必要删除测试代码。

若进行了任何形式的改动,可方便地返回测试。

这些代码也可作为如何使用类的一个示例使用。

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

可使库的某一部分“公共化”(一个方法、类或者一个字段等等),就永远不能把它拿出。

若强行拿出,就可能破坏其他人现有的代码,使他们不得不重新编写和设计。

若只公布自己必须公布的,就可放心大胆地改变其他任何东西。

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

4、尽量使用interfaces,不要使用abstract类。

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

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

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

7JSP编码规范

1、整个jsp/jspbean表示层应当尽可能的瘦和简单化。

2、牢记大多数的JSP都应当是只读的视图,而由页面bean来提供模型。

3、应当一起设计JSP和JSPbean。

4、在尽可能合理的情况下,把业务逻辑从JSP中移走。

具体于HTTP的逻辑(如,对Cookie的处理)属于bean或支持类中,而不是JSP中。

5、尽量把条件逻辑放在控制器中而不是放在视图中。

6、为JSP、包含的文件、JSPBean和实现扩展标记的类使用遵循标准的命名惯例。

如:

jsp控制器:

xxxxController.jsp

被包含的:

jsp_descriptiveNameOfFragme

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 人文社科 > 法律资料

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2