Java语言编码规范- 副本

Java语言编码规范

Java语言编码规范 (Java Code Conventions)

第 1 页 共 19 页

Java语言编码规范

目 录

一、 规范简介 .................................................................................................... 4

1 目的 .................................................................................................................................................. 4 2 范围 .................................................................................................................................................. 4 3 参考文档 .......................................................................................................................................... 4 4 说明 .................................................................................................................................................. 4

二、 通用命名规则 ............................................................................................. 4

1.1 包(package) .............................................................................................. 4 1.2 类(class) ................................................................................................... 4 1.3 接口(interface) .......................................................................................... 2 1.4 方法(method) ............................................................................................ 2 1.5 变量(variable) ........................................................................................... 2 1.6 常量(constant) .......................................................................................... 2

三、 CHECKITEM、CHECKLINE的标记 ......................................................... 2 四、 JAVA编码规范 .......................................................................................... 3

1 文件 .................................................................................................................................................. 3

1.1 文件布局格式设置 ..................................................................................... 3 1.2 类的设计 ................................................................................................... 3 1.3 包和引用(package & import) ..................................................................... 4 1.4 注释(comment) ......................................................................................... 4

2 声明(DECLARATIONS)........................................................................................................................... 5

2.1 每行声明变量的数量(Number Per Line) ................................................... 5 2.2 初始化(Initialization) .......................................................................... 5 2.3 布局(Placement) ...................................................................................... 5

第 2 页 共 19 页

Java语言编码规范

2.4 类和接口的声明(Class and Interface Declarations) ............................ 6

3 语法规则 .......................................................................................................................................... 6

1. 关于循环语句 ............................................................................................... 7 2. 关于条件语句 ............................................................................................... 7 3. 关于变量 ...................................................................................................... 8 4. 关于类型转换 ............................................................................................... 8 5. 关于try /catch ............................................................................................... 9 6. 关于return .................................................................................................... 9 7. 杂项 ............................................................................................................. 9

8. 空白(White Space) .............................................................................. 10

空行(Blank Lines) ........................................................................................ 10 空格(Blank Spaces) ...................................................................................... 10

4 编程惯例(PROGRAMMING PRACTICES) .................................................................................................. 11

4.1 提供对实例以及类变量的访问控制(Providing Access to Instance and Class Variables) .......................................................................................... 11 4.2 引用类变量和类方法(Referring to Class Variables and Methods) ..... 11 4.3 常量(Constants) .................................................................................... 11 4.4 变量赋值(Variable Assignments) .......................................................... 11 4.5 其它惯例(Miscellaneous Practices) ..................................................... 12

5 性能考虑 ........................................................................................................................................ 13

5.1 使用 StringBuffer 对象 ........................................................................ 13 5.2 可移植性 ................................................................................................. 13 5.3 换行 ........................................................................................................ 13 5.4 PrintStream ........................................................................................... 14

6 JBUILDER的编码风格 .................................................................................................................... 14

第 3 页 共 19 页

Java语言编码规范

7 《THINKING IN JAVA》中关于JAVA程序设计的建议 .................................................................. 14

第一章 规范简介

目的

制订本规范的目的是为培养规范设计和编程，养成良好的习惯，增强JAVA类软件产品的稳定、健壮、

可靠性;同时也为提高软件的可读性，可以让程序员尽快而彻底地理解新的代码，使产品可维护性提高而制定的强制性规范，同时也是代码复审的依据。

范围

本规范适用于公司JAVA类代码（包括JSP）的代码编写标准。适用于代码编写阶段和代码维护阶段。

参考文档

《SUN JAVA代码编写规范》。 《Java编程思想》

说明

本文档包括java编码规范。

第二章 通用命名规则

2.1.

包(package)

包名在整个系统必须唯一，必须全部小写，短小而且具有一定的实际意义，如可以按照不同的应用目

的或模块进行划分。 包名以”.”分隔，范围从大到小。在本公司，包名均以”com.isoftstone”开头。

2.2. 类(class)

类名命名一般来说是名词结构的，首字母应大写。类名应具有明确的含义，能在一定程度上表达类的功能。在有多个单词组成的类名中，每个单词的第一个字母必须大写，如果类名过长，可以采用缩写的方式。缩写的单词须具有清晰的含义。

第 4 页 共 19 页

2.3. 接口(interface)

接口的命名规则同类的命名规则相同，但应以”If”开头来代表接口。

2.4. 方法(method)

方法的命名一般来说是动词结构的（通常对第一个单词要求是动词），且要求第一个单词的首字母是小写的，要求有清晰的方法含义。在有多单词组合中，要求第一个单词的首字母小写且具有动词意义，其余单词组合的首字母应该大写。在方法名过长的情况下，可考虑缩写，但必须意义明确。

2.5. 变量(variable)

变量的命名要求尽量具有明确的含义，首字母应小写，避免以”_”或”$”作为开头。

2.6. 常量(constant)

常量命名要求具有明确的含义，所有字母应全部大写。多个单词组合时，以”_”下划线连接。

当多个常量表示一个类型的不同特征或状态值时，应将共同的部分作为名称的前段，从而在使用IDE工具自动列出成员时能同时见到这些常量。如，表示缓存长度的最大和最小值的两个常量，建议分别命名为BUF_LEN_MAX和BUF_LEN_MIN，而不是MAX_BUF_LEN和MIN_BUF_LEN。

第三章 CheckItem、CheckLine的标记

为便于代码量的统计以及维护阶段跟踪代码的变化，需要在所有提交的文件中加入CheckItem、

CheckLine标记。说明如下：

CheckItem用于在文件的头部作标注。

CheckLine用于在文件具体修改的地方作标注。 举例说明如下：

@CheckItem@ NEW-zhangming-20051128-MISCOAM17-add100 新增 @CheckLine@ NEW-zhangming-20051128-MISCOAM17-add100 新增 NEW 这部分表示含义如下：

NEW 代表新添加的代码

OPT 代表优化时修改的代码 BUG 测试出现bug时修改的代码

Zhangming 这部分代表作者，不需要用汉字表示，直接用拼音

20051128 这部分代表代码改动的日期，格式为YYYYMMDD

-2-

MISCOAM17 这部分代表本次编码的版本号

add100 这部分代表对文件的何种操作 ，以及操作影响的行数

新增用ADD表示

修改用MOD表示（删除代码也是MOD）

最后一部分表示这次操作的简单描述

a) 新文件的新增标记：

新文件中只需要CheckItem标记就可以了，不需要CheckLine b) 已存在文件的删除、修改、新增文件标记 需要CheckItem和CheckLine

第四章 java编码规范

文件

4.1.

文件布局格式设置

Java文件布局格式参照“四 JBuilder的编码风格”。

注：所有的缩进由“Space(空格)键”形成的，而不是“Tab键”。

应在各方法之间加入一些空行来分割大段的代码。 方法与方法之间加入一两行的空格行。

一行代码的长度不应超过120个字符，建议少于80个字符。若一行代码向右延伸得很长，就应该考虑把它分割成更多的方法。

一个文件的长度不宜超过2000行，如果过大，应该考虑拆分或其他办法。 文件内容尽量如下循序所示： package import

final attributes attributes

constructors methods

4.2. 类的设计

类应尽可能的短小，只解决某个特定问题。

-3-

4.3. 包和引用(package & import)

对于有包说明的java文件，包说明必须放在该文件的第一行。

对于引用，尽量引用全称，如”import java.util.HashMap;”，而不要作如下引用如”import java.util.*;”。 尽量把引用的功能相同（父包相同）放置在相近的位置，文件代码完成后，对于没有使用到的引用，需要删除。

4.4. 注释(comment)

大部分注释尽量用”//”，对于所有的javadoc的注释则用“/** */”，而临时对代码块进行的注释尽量用“/* */”。

注释在java文件中占有重要的地位，应该尽量做到完善：

? 每个类必须加注释说明类功能

? 每个函数应加注释说明函数功能和参数 ? 关键算法必须加注释 ? 关键变量应加注释

在JBuilder中关于注释的方法很多，通过这种注释，除了阅读代码方便之外，还可以用javadoc生成完整的文档，以下分别说明： 文件概要注释

该注释一般时对该java文件作概要说明，包括版本信息、作者、所包含的主要功能等。JBuilder中的形式如下： /**

*

Title:

Description:

Copyright:

Company:

方法注释

方法注释主要是说明该方法功能、输入、输出、异常参数，格式如下： /**

* 插入行数据到表T_North_Tabular_OID ---功能说明

* @param mibNode com.aspire.platform.snmp.MibNode---入参说明 * @param ---入参说明 * @return Boolean ---出参说明 * @throws FrameException ---异常说明 */

变量注释

对于变量注释，可分为2种。

-4-

一是对于具有set/get方法的属性变量，一般都采用如下方式： /** persistent field */ private String levelall;

一是对于一般的变量，一般采用的方式如下： private String strName; //名称变量

声明(Declarations)

4.5. 每行声明变量的数量(Number Per Line)

推荐一行一个声明，因为这样以利于写注释。亦即， int level; // indentation level int size; // size of table 要优于，

int level, size;

不要将不同类型变量的声明放在同一行，例如： int foo, fooarray[]; //WRONG!

注意：上面的例子中，在类型和标识符之间放了一个空格，另一种被允许的替代方式是使用制表符： int level; // indentation level int size; // size of table

Object currentEntry; // currently selected table entry

4.6. 初始化(Initialization)

尽量在声明局部变量的同时初始化。唯一不这么做的理由是变量的初始值依赖于某些先前发生的计算。

4.7. 布局(Placement)

只在代码块的开始处声明变量。（一个块是指任何被包含在大括号\和\中间的代码。）不要在首次用到该变量时才声明之。这会把注意力不集中的程序员搞糊涂，同时会妨碍代码在该作用域内的可移植性。 void myMethod() {

int int1 = 0; // beginning of method block

if (condition) {

int int2 = 0; // beginning of \ ...

-5-

} }

该规则的一个例外是for循环的索引变量

for (int i = 0; i < maxLoops; i++) { ... }

避免声明的局部变量覆盖上一级声明的变量。例如，不要在内部代码块中声明相同的变量名： int count; ...

myMethod() {

if (condition) {

int count = 0; // AVOID! ... } ... }

4.8. 类和接口的声明(Class and Interface Declarations)

当编写类和接口是，应该遵守以下格式规则：

- 在方法名与其参数列表之前的左括号\间不要有空格 - 左大括号\位于声明语句同行的末尾

- 右大括号\另起一行，与相应的声明语句对齐，除非是一个空语句，\应紧跟在\之后 class Sample extends Object { int ivar1; int ivar2;

Sample(int i, int j) { ivar1 = i; ivar2 = j; }

int emptyMethod() {}

... }

- 方法与方法之间以空行分隔

语法规则

本节定义一些基本常用的规则，说明一些应该注意和避免的地方。

-6-

1. 关于循环语句

1) for循环

不要在for循环内部作与循环控制无关的变量操作，如:

sum = 0; // NOT: for (i=0, sum=0; i<100; i++) for (int i=0; i<100; i++) { sum += value[i];

2)

}

while循环

在使用循环之前，一定要先初始化控制变量，如： boolean isDone = true; //NOT while(isDone) while(isDone){ //do something }

避免使用do ….while循环。

如果使用空循环，尽量使用for(;;)而避免使用while(true)来作空循环。

尽量少用”continue”, continue会给将来把一个结构拆分成几个更小的结构或方法带来许多困难；而且她也会迫使开发者不得不为该结构考虑多于一个的结束点。

尽量少用“break”，除非是转换状态（switch statement）控制, 在转换状态控制之外的情况下使用break，会给将来把一个结构拆分成几个更小的结构或方法带来许多困难；而且她也会迫使开发者不得不为该结构考虑多于一个的结束点。

对于数组和列表类型变量arr的循环，其循环截止条件建议使用

i < len;//其中len 已预先赋值为 arr.length或arr.size()

不要使用

i < arr.length;//或者i < arr.size()

在JVM1.4下的性能测试表明，对于有循环体的循环，前者比后者优10%以上；但对于无循环体的循环，前者比后者差。

3) 4) 5) 6)

7)

2. 关于条件语句

避免使用过于复杂的条件判断，如果存在复杂的条件判断，应该使用变量来替换，如： 尽量不要使用：

if((elementNo < 0) || (elementNo > maxElement)|| (elementNo == lastElement)){ doSomething(); }

而应该使用如下格式：

boolean finished = (elementNo < 0) || (elementNo > maxElement); boolean repeatedEntry = elementNo == lastElement; if (finished || repeatedEntry) {

doSomething();

}

对于每一个小的条件，都应该加上(),如下所示：

-7-

if (a == b && c == d)//避免使用 if ((a == b) && (c == d))//常用

在使用if…else时，尽量把多发生的情况放在前面，而不是放在后面,如：

boolean error = readFile (fileName);

if (!error) {//通常情况下，文件的读取都是正常的

doSomething();

}

else {

doSomething();

}

尽量把if条件和要处理的事务分开为两行，如：

if (done)// NOT: if (done) doSomething(); doSomething();

在条件语句中，不要放置执行语句，如：

file = openFile (fileName, \ if (file != null) { doSomething(); } 而不是

if ((file = openFile (fileName, \ doSomething(); }

3. 关于变量

1) 2) 3) 4) 5) 6)

最好总是在每个变量出现的时候就马上进行初始化。

最好只在需要的时候再声明（declare）一个变量，否则将影响代码的执行效果。 变量的作用域应该尽可能的小，尽量不使用全局变量。 绝不在程序中声明意义相同的变量。 类变量不声明为public。 变量生命周期应尽量短。

4. 关于类型转换

类型转换一定要明确清晰，不要模糊转换，如：

floatValue = (float) intValue; // NOT: floatValue = intValue;

-8-

5. 关于try /catch

try/catch一般有两种用法，

一种是不带有系统资源的，可直接使用，如下：

try {

statements;

} catch (ExceptionClass e) { statements; }

一种是在带有资源释放的，如数据库连接的释放，文件的关闭等等，这些通常会在方法的最后作释放工作，采用带有finally的try/catch用法,这种用法的好处是，方法在退出之前，一定会执行finally中的操作，所以对于释放资源一类的操作，统一放在finally中是很好的处理方法,如下:

try {

statements;

} catch (ExceptionClass e) { statements; } finally {

statements; }

6. 关于return

不要在一个方法的中间使用“return”, “return”只能出现在一个方法的末尾。在方法的中间使用“return”会给今后将方法拆分成几个更小的方法带来困难；而且它会迫使开发者不得不为该方法考虑多于一个的出口点。

7. 杂项

尽量使用StringBuffer代替String用于可变字符串。若能预知可变字符串的最大长度，或在绝大多数场合下的最大长度，应使用此长度作为StringBuffer构造函数的参数，以避免在多数场合下需要为StringBuffer重新分配内存。

ArrayList与StringBuffer类同，若能预知列表的最大长度，或在绝大多数场合下的最大长度，应使用此长度作为ArrayList构造函数的参数，以避免在多数场合下需要为ArrayList重新分配内存。

-9-

8. 空白(White Space) 空行(Blank Lines)

空行将逻辑相关的代码段分隔开，以提高可读性。 下列情况应该总是使用两个空行：

- 一个源文件的两个片段(section)之间 - 类声明和接口声明之间

下列情况应该总是使用一个空行： - 两个方法之间

- 方法内的局部变量和方法的第一条语句之间

- 一个方法内的两个逻辑段之间，用以提高可读性

空格(Blank Spaces)

下列情况应该使用空格：

- 一个紧跟着括号的关键字应该被空格分开，例如： while (true) { ... }

注意：空格不应该置于方法名与其左括号之间。这将有助于区分关键字和方法调用。 - 空白应该位于参数列表中逗号的后面 - 所有的二元运算符，除了\，应该使用空格将之与操作数分开。一元操作符和操作数之间不因该加空格，比如：负号(\、自增(\和自减(\。例如： a += c + d;

a = (a + b) / (c * d);

while (d++ = s++) { n++; }

printSize(\

- for语句中的表达式应该被空格分开，例如： for (expr1; expr2; expr3)

- 强制转型后应该跟一个空格，例如： myMethod((byte) aNum, (Object) x);

myMethod((int) (cp + 5), ((int) (i + 3)) + 1);

-10-

编程惯例(Programming Practices)

4.9. 提供对实例以及类变量的访问控制(Providing Access to Instance and Class Variables)

若没有足够理由，不要把实例或类变量声明为公有。通常，实例变量无需显式的设置(set)和获取(gotten)，通常这作为方法调用的边缘效应 (side effect)而产生。

一个具有公有实例变量的恰当例子，是类仅作为数据结构，没有行为。亦即，若你要使用一个结构(struct)而非一个类(如果java支持结构的话)，那么把类的实例变量声明为公有是合适的。

4.10. 引用类变量和类方法(Referring to Class Variables and Methods)

避免用一个对象访问一个类的静态变量和方法。应该用类名替代。例如： classMethod(); //OK AClass.classMethod(); //OK anObject.classMethod(); //AVOID!

4.11. 常量(Constants)

位于for循环中作为计数器值的数字常量，除了-1,0和1之外，不应被直接写入代码。

4.12. 变量赋值(Variable Assignments)

避免在一个语句中给多个变量赋相同的值。它很难读懂。例如： fooBar.fChar = barFoo.lchar = 'c'; // AVOID!

不要将赋值运算符用在容易与相等关系运算符混淆的地方。例如： if (c++ = d++) { // AVOID! (Java disallows) ... } 应该写成

if ((c++ = d++) != 0) { ... }

不要使用内嵌(embedded)赋值运算符试图提高运行时的效率，这是编译器的工作。例如：

-11-

d = (a = b + c) + r; // AVOID! 应该写成 a = b + c; d = a + r;

4.13. 其它惯例(Miscellaneous Practices)

4.13.1.

圆括号(Parentheses)

一般而言，在含有多种运算符的表达式中使用圆括号来避免运算符优先级问题，是个好方法。即使运算符的优先级对你而言可能很清楚，但对其他人未必如此。你不能假设别的程序员和你一样清楚运算符的优先级。

if (a == b && c == d) // AVOID! if ((a == b) && (c == d)) // RIGHT

4.13.2. 返回值(Returning Values)

设法让你的程序结构符合目的。例如： if (booleanExpression) { return true; } else {

return false; }

应该代之以如下方法：

return booleanExpression; 类似地：

if (condition) { return x; }

return y; 应该写做：

return (condition ? x : y);

4.13.3.

条件运算符\前的表达式(Expressions before '?' in the Conditional

-12-

Operator)

如果一个包含二元运算符的表达式出现在三元运算符\的\之前，那么应该给表达式添上一对圆括号。例如：

(x >= 0) ? x : -x;

4.13.4. 特殊注释(Special Comments)

在注释中使用XXX来标识某些未实现(bogus)的但可以工作(works)的内容。用FIXME来标识某些假的和错误的内容。

性能考虑

4.14. 使用 StringBuffer 对象

在处理String的时候要尽量使用StringBuffer类，StringBuffer类是构成String类的基础。String类将StringBuffer类封装了起来，（以花费更多时间为代价）为开发人员提供了一个安全的接口。当我们在构造字符串的时候，我们应该用StringBuffer来实现大部分的工作，当工作完成后将StringBuffer对象再转换为需要的 String 对象。比如：如果有一个字符串必须不断地在其后添加许多字符来完成构造，那么我们应该使用StringBuffer对象和她的append()方法。如果我们用String对象代替StringBuffer对象的话，会花费许多不必要的创建和释放对象的CPU时间。

避免太多的使用synchronized关键字避免不必要的使用关键字synchronized，应该在必要的时候再使用她，这是一个避免死锁的好方法。

4.15. 可移植性

BorlandJbulider不喜欢synchronized这个关键字，如果你的断点设在这些关键字的作用域内的话，调试的时候你会发现的断点会到处乱跳，让你不知所措。除非必须，尽量不要使用。

4.16. 换行

如果需要换行的话，尽量用 println 来代替在字符串中使用\。 你不要这样：

System.out.print(\要这样：

System.out.println(\

或者你构造一个带换行符的字符串，至少要象这样：

-13-

String newline = System.getProperty(\System.out.println(\

4.17. PrintStream

PrintStream 已经被不赞成（deprecated）使用，用 PrintWrite 来代替她。

JBuilder的编码风格

JBuilder可为工程使用统一的编码风格，编码风格可从文件导入，也可导出到文件。

目前定义的编码风格文件——oam.codestyle，是在Java Standard的基础上做了几处小的修改而成。 编码风格文件导入方法： 1. 打开JBuilder

2. 关闭所有打开的工程

3. 打开菜单：Project -> Default Project Properties …

4. 打开Formatting项，单击按钮”Imporing…”导入待用的codestyle文件。

《Thinking in Java》中关于Java程序设计的建议

(1) 类名首字母应该大写。字段、方法以及对象（句柄）的首字母应小写。对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。例如： ThisIsAClassName

thisIsMethodOrFieldName

若在定义中出现了常数初始化字符，则大写static final基本类型标识符中的所有字母。这样便可标志出它们属于编译期的常数。

Java包（Package）属于一种特殊情况：它们全都是小写字母，即便中间的单词亦是如此。对于域名扩展名称，如com，org，net或者edu等，全部都应小写（这也是Java 1.1和Java 1.2的区别之一）。 (2) 为了常规用途而创建一个类时，请采取“经典形式”，并包含对下述元素的定义： equals() hashCode() toString()

clone()（implement Cloneable） implement Serializable

(3) 对于自己创建的每一个类，都考虑置入一个main()，其中包含了用于测试那个类的代码。为使用一个项目中的类，我们没必要删除测试代码。若进行了任何形式的改动，可方便地返回测试。这些代码也可作为如何使用类的一个示例使用。

(4) 应将方法设计成简要的、功能性单元，用它描述和实现一个不连续的类接口部分。理想情况下，方法应简明扼要。若长度很大，可考虑通过某种方式将其分割成较短的几个方法。这样做也便于类内代码的重复使用（有些时候，方法必须非常大，但它们仍应只做同样的一件事情）。

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

-14-

处地为管理代码的人考虑一下（预计有可能进行哪些形式的修改，想想用什么方法可把它们变得更简单）。 (6) 使类尽可能短小精悍，而且只解决一个特定的问题。下面是对类设计的一些建议： ■一个复杂的开关语句：考虑采用“多形”机制

■数量众多的方法涉及到类型差别极大的操作：考虑用几个类来分别实现 ■许多成员变量在特征上有很大的差别：考虑使用几个类

(7) 让一切东西都尽可能地“私有”——private。可使库的某一部分“公共化”（一个方法、类或者一个字段等等），就永远不能把它拿出。若强行拿出，就可能破坏其他人现有的代码，使他们不得不重新编写和设计。若只公布自己必须公布的，就可放心大胆地改变其他任何东西。在多线程环境中，隐私是特别重要的一个因素——只有private字段才能在非同步使用的情况下受到保护。

(8) 谨惕“巨大对象综合症”。对一些习惯于顺序编程思维、且初涉OOP领域的新手，往往喜欢先写一个顺序执行的程序，再把它嵌入一个或两个巨大的对象里。根据编程原理，对象表达的应该是应用程序的概念，而非应用程序本身。

(9) 若不得已进行一些不太雅观的编程，至少应该把那些代码置于一个类的内部。 (10) 任何时候只要发现类与类之间结合得非常紧密，就需要考虑是否采用内部类，从而改善编码及维护工作。

(11) 尽可能细致地加上注释，并用javadoc注释文档语法生成自己的程序文档。

(12) 避免使用“魔术数字”，这些数字很难与代码很好地配合。如以后需要修改它，无疑会成为一场噩梦，因为根本不知道“100”到底是指“数组大小”还是“其他全然不同的东西”。所以，我们应创建一个常数，并为其使用具有说服力的描述性名称，并在整个程序中都采用常数标识符。这样可使程序更易理解以及更易维护。 (13) 涉及构建器和异常的时候，通常希望重新丢弃在构建器中捕获的任何异常——如果它造成了那个对象的创建失败。这样一来，调用者就不会以为那个对象已正确地创建，从而盲目地继续。 (14) 当客户程序员用完对象以后，若你的类要求进行任何清除工作，可考虑将清除代码置于一个良好定义的方法里，采用类似于cleanup()这样的名字，明确表明自己的用途。除此以外，可在类内放置一个boolean（布尔）标记，指出对象是否已被清除。在类的finalize()方法里，请确定对象已被清除，并已丢弃了从RuntimeException继承的一个类（如果还没有的话），从而指出一个编程错误。在采取象这样的方案之前，请确定finalize()能够在自己的系统中工作（可能需要调用System.runFinalizersOnExit(true)，从而确保这一行为）。

(15) 在一个特定的作用域内，若一个对象必须清除（非由垃圾收集机制处理），请采用下述方法：初始化对象；若成功，则立即进入一个含有finally从句的try块，开始清除工作。

(16) 若在初始化过程中需要覆盖（取消）finalize()，请记住调用super.finalize()（若Object属于我们的直接超类，则无此必要）。在对finalize()进行覆盖的过程中，对super.finalize()的调用应属于最后一个行动，而不应是第一个行动，这样可确保在需要基础类组件的时候它们依然有效。

(17) 创建大小固定的对象集合时，请将它们传输至一个数组（若准备从一个方法里返回这个集合，更应如此操作）。这样一来，我们就可享受到数组在编译期进行类型检查的好处。此外，为使用它们，数组的接收者也许并不需要将对象“造型”到数组里。

(18) 尽量使用interfaces，不要使用abstract类。若已知某样东西准备成为一个基础类，那么第一个选择应是将其变成一个interface（接口）。只有在不得不使用方法定义或者成员变量的时候，才需要将其变成一个abstract（抽象）类。接口主要描述了客户希望做什么事情，而一个类则致力于（或允许）具体的实施细节。

(19) 在构建器内部，只进行那些将对象设为正确状态所需的工作。尽可能地避免调用其他方法，因为那些方法可能被其他人覆盖或取消，从而在构建过程中产生不可预知的结果（参见第7章的详细说明）。 (20) 对象不应只是简单地容纳一些数据；它们的行为也应得到良好的定义。

(21) 在现成类的基础上创建新类时，请首先选择“新建”或“创作”。只有自己的设计要求必须继承时，才应考虑这方面的问题。若在本来允许新建的场合使用了继承，则整个设计会变得没有必要地复杂。

-15-

(22) 用继承及方法覆盖来表示行为间的差异，而用字段表示状态间的区别。一个非常极端的例子是通过对不同类的继承来表示颜色，这是绝对应该避免的：应直接使用一个“颜色”字段。

(23) 为避免编程时遇到麻烦，请保证在自己类路径指到的任何地方，每个名字都仅对应一个类。否则，编译器可能先找到同名的另一个类，并报告出错消息。若怀疑自己碰到了类路径问题，请试试在类路径的每一个起点，搜索一下同名的.class文件。

(24) 在Java 1.1 AWT中使用事件“适配器”时，特别容易碰到一个陷阱。若覆盖了某个适配器方法，同时拼写方法没有特别讲究，最后的结果就是新添加一个方法，而不是覆盖现成方法。然而，由于这样做是完全合法的，所以不会从编译器或运行期系统获得任何出错提示——只不过代码的工作就变得不正常了。 (25) 用合理的设计方案消除“伪功能”。也就是说，假若只需要创建类的一个对象，就不要提前限制自己使用应用程序，并加上一条“只生成其中一个”注释。请考虑将其封装成一个“独生子”的形式。若在主程序里有大量散乱的代码，用于创建自己的对象，请考虑采纳一种创造性的方案，将些代码封装起来。

(26) 警惕“分析瘫痪”。请记住，无论如何都要提前了解整个项目的状况，再去考察其中的细节。由于把握了全局，可快速认识自己未知的一些因素，防止在考察细节的时候陷入“死逻辑”中。

(27) 警惕“过早优化”。首先让它运行起来，再考虑变得更快——但只有在自己必须这样做、而且经证实在某部分代码中的确存在一个性能瓶颈的时候，才应进行优化。除非用专门的工具分析瓶颈，否则很有可能是在浪费自己的时间。性能提升的隐含代价是自己的代码变得难于理解，而且难于维护。

(28) 请记住，阅读代码的时间比写代码的时间多得多。思路清晰的设计可获得易于理解的程序，但注释、细致的解释以及一些示例往往具有不可估量的价值。无论对你自己，还是对后来的人，它们都是相当重要的。如对此仍有怀疑，那么请试想自己试图从联机Java文档里找出有用信息时碰到的挫折，这样或许能将你说服。

(29) 如认为自己已进行了良好的分析、设计或者实施，那么请稍微更换一下思维角度。试试邀请一些外来人士——并不一定是专家，但可以是来自本公司其他部门的人。请他们用完全新鲜的眼光考察你的工作，看看是否能找出你一度熟视无睹的问题。采取这种方式，往往能在最适合修改的阶段找出一些关键性的问题，避免产品发行后再解决问题而造成的金钱及精力方面的损失。

(30) 良好的设计能带来最大的回报。简言之，对于一个特定的问题，通常会花较长的时间才能找到一种最恰当的解决方案。但一旦找到了正确的方法，以后的工作就轻松多了，再也不用经历数小时、数天或者数月的痛苦挣扎。我们的努力工作会带来最大的回报（甚至无可估量）。而且由于自己倾注了大量心血，最终获得一个出色的设计方案，成功的快感也是令人心动的。坚持抵制草草完工的诱惑——那样做往往得不偿失。

-16-

本文来源：https://www.bwwdw.com/article/zpv8.html