java通用工具需要不要写成static_Java编程规范

handleException(e);

}

9、运算符

每个运算符与操作数之间都应有空格分隔，例如：

b = true

a > b && a < c

不能写成：

b=true

a>b&&a

10、数组

数组的定义应写成：

int[] indices;

而不要写成：

int indices[];

11、字体

编辑Java源代码的文本编辑器字体应该设定为等宽字体，例如“Curier”，不应使用非等宽字体，例如“Times

New Roman”，因为使用非等宽字体不利于控制代码的缩进与对齐。

第三部分 程序编写

1、exit方法

System.exit()方法应该只在main方法中被调用，而不出现在程序的其他任何地方。最好的做法是在main方法中也不调用System.exit()方法，因为main方法结束，主线程自动退出。

2、异常处理

如果代码执行的过程中，捕获了一个异常，绝对不能简单地将这个异常“吃”掉或是打印一些类似于“1111111”的信息，而是应该谨慎对待——因为异常包含了程序执行过程中的原始错误信息，良好的异常处理策略可以为后期的调试、维护等工作带来极大的便利。

从功能的角度来看，代码中捕获的异常通常分为两种情况：可以预见的和不可预见的。不可预见的异常是指在代码编写期间没有考虑到或无法考虑到的异常情况，例如进行数据库访问时连接突然中断。可以预见的异常是指代码编写期间就可以考虑到的“合理”异常，例如将字符串解析为数字时引发的NumberFormatException。

异常的处理应该以方法为单位，也就是说，某个方法内部捕获到一个异常时，应该由该方法决定如何处理此异常。

对于可以预见的异常，可以采取两种处理策略：处理异常或抛出异常。处理异常是指该异常在当前方法的处理能力之内，该方法可以自行处理此异常。例如，用户输入某个字符串后，要求程序自行解析，如果为数字，则视为用户的身份号码；如果不为数字，则视为用户的姓名。假定解析用户输入字符串的方法名为parseInput，那么在parseInput方法执行的过程中，可能会引发NumberFormatException。这个异常对于parseInput而言是可以预见的，并且是它可以自行处理的，那么它应该自己捕获此异常，而不必将其另行抛出。

假如在上面的例子中，用户姓名的合法性本身还有一套校验规则，那么在parseInput方法中处理了NumberFormatException之后，执行用户姓名校验时还有可能引发异常。这个异常虽然也是可以预见的，但是已经超出了parseInput方法的职责范围，它应该将此异常继续抛出。抛出的异常会被更外围的方法捕获，由它们最终决定如何处理该异常，例如提示用户或中止程序。

对于不可预见的异常，只有一种策略可以采用：继续抛出。

对于每个方法而言，处理异常的原则就是：在自己职责范围之内的异常，一定要自己处理，而不能抛出；在自己职责范围之外的异常，则一定要抛出，绝对不能自行处理(例如把它“吃掉”)。

应该选择“处理异常”还是“抛出异常”并没有严格的标准，往往要依靠经验并从实际的需求出发。但是通常而言，选择“处理异常”策略的方法都属于程序“较外围”(即在调用堆栈中处于比较底层)的业务控制方法，因为只有它们知道业务需求，只有它们才能决定发生某个异常时应该通知用户、记入日志还是中止程序。对于大多数工具方法或通用方法而言，它们并不了解实际的业务需求，在异常发生时，它们最好的选择就是“抛出异常”策略——将异常原封不动地抛给外围的业务控制方法，由它们作出决定。

3、状态判断

在可能的情况下，应该尽量使用异常而不是返回值来表示某个方法的执行状态。某个方法可以在任何需要的时候抛出异常，而不仅仅是在发生错误的时候。例如，一个校验用户身份的方法如下：

boolean authenticate(String user, String password);

使用该方法校验用户身份只能返回“true”或“false”，表示用户校验通过与否，对于校验不通过的情况，该方法无法返回更多的信息。如果将该方法设计成如下的样子：

void authenticate(String user, String password) throws

Exception;

调用该方法时，如果没有引发异常，表示用户校验通过；如果发生异常，则表示校验未通过。根据抛出的异常，还可以进一步得到校验未通过的原因，并且可以将异常的详细信息反馈给用户或记入日志。这样的设计不但可以带来更好的用户体验，而且极大地方便了以后程序的调试和维护。

一个异常包含的信息远远比一个简单的返回值丰富的多。

4、垃圾回收

不要迷信垃圾回收。

由于finalize方法的调用不是可靠的，并且调用的时间是不可预知的，因此不要依赖垃圾回收机制使用finalize方法来做清理工作。

例如，如果使用了java.sql.Connection对象，即使不调用它的close方法，系统也会在垃圾回收时清理它所使用的资源。但是这种方法并不可取，尤其是对频繁使用数据库连接的程序而言——因为很有可能在系统执行垃圾回收之前，已经堆积了大量无用的Connection对象，占用了大量的系统资源，影响系统的执行效率。最好的方法还是在一个Connection对象使用完毕后马上调用它的close方法显式释放资源。

除此之外，除非你编写的是非常基础的服务程序，否则不要轻易调用System.gc()或Runtime.gc()方法，因为垃圾回收的过程本身会占用系统资源，垃圾回收的过程调用不当的话，非但不会提高系统效率，反倒会影响系统的运行。

5、终态类(final class)

不要为了提高系统的性能而设计任何终态类(当然，有特殊需求的情况除外)。很可能在未来的某个时候被设计为终态的类需要被派生。

6、工具类

工具类用来提供一组通用的公共方法。

工具类应该设计成为拥有一组静态的工具方法，因而不需要实例化就可以使用；

工具类可以有一组静态终态(static

final)字段表示通用常量，但是不应有任何非静态字段；

工具类应该声明一个私有的缺省构造函数，以防止被继承或被实例化。

7、System.out和System.err

不要滥用System.out和System.err。

在编写程序、单元测试和后期调试的时候，很多人喜欢直接或间接地使用System.out和System.err打印调试信息(Throwable.printStackTrace也间接使用了System.err)。当程序最终发布的时候，如果忘了删除这些调试信息，会造成很多“垃圾”输出，严重的时候，这些“垃圾”输出会导致日志文件迅速挤满硬盘。

建议使用java.util.logging或其他一些第三方的工具包来打印调试信息，而不要直接使用System.out或System.err。当然，也可以自行编写一个简单的Debug工具类实现调试信息的输出。这样，当程序发布时，只需要进行简单的修改或配置，就可以除去所有的调试信息。

8、静态方法

静态方法一定要静态调用，而不要使用实例。例如，要挂起当前线程，应该调用“Thread.sleep(1000);”而不是“Thread.currentThread().sleep(1000);”。

9、StringBuffer

在对字符串进行较多的拼接、拆分工作时，应尽量使用StringBuffer对象，而不是直接对String对象操作。

10、代码复用

千万不要使用过多的“复制、粘贴”实现代码的复用。如果一段代码被复制、粘贴了超过3次，就应该考虑将这段代码重新封装到一个方法中。如果出现第4个地方需要使用这段代码，并且需要对代码作稍许改动，则应该考虑将刚才封装的方法进行改造而不是重新定义一个方法。

不要认为使用复制、粘贴会比重新封装一个方法节省时间。因为在将来项目进行到某一阶段的时候，这段代码可能被复制了200份，并且改动了300处，这个时候如果这段代码的逻辑发生变化——哪怕是微小的变化，无论是重新找到并修改这200处地方，还是回头重新将他们封装为一个方法，工作量都将是惊人的。