说明:NullPointException抛出时常常描述为空,这样往往看不出是出了什么错。 示例: try
{
... }
catch (FileNotFoundException e) {
logger.error(e); }
建议2 一个方法不应抛出太多类型的异常。(1.42+)
说明: 如果程序中需要分类处理,则将异常根据分类组织成继承关系。如果确实有很多异常类型首先考虑用异常描述来区别,throws/exception子句标明的异常最好不要超过三个。
建议3 异常捕获尽量不要直接 catch (Exception ex),应该把异常细分处理。(1.42+) 说明:可以设计更合理异常处理分支
建议4 如果多段代码重复做同一件事情,那么在方法的划分上可能存在问题。(1.42+) 说明:若此段代码各语句之间有实质性关联并且是完成同一件功能的,那么可考虑把此段代码构造成一个新的方法。
建议5 集合中的数据如果不使用了应该及时释放,尤其是可重复使用的集合。(1.42+) 说明:由于集合保存了对象的引用,虚拟机的垃圾收集器就不会回收。
建议6 源程序中关系较为紧密的代码应尽可能相邻。(1.42+) 说明:便于程序阅读和查找。
示例:矩形的长与宽关系较密切,放在一起。 rect.length = 10; rect.width = 5;
建议7 不要使用难懂的技巧性很高的语句,除非很有必要时。(1.42+)
说明:高技巧语句不等于高效率的程序,实际上程序的效率关键在于设计与算法。
建议8 明确方法功能,精确(而不是近似)地实现方法设计。一个函数仅完成一件功能,即使
简单功能也编写方法实现。 (1.42+)
说明:虽然为仅用一两行就可完成的功能去编方法好象没有必要,但用方法可使功能明确化,增加程序可读性,亦可方便维护、测试。
建议9 应明确规定对接口方法参数的合法性检查应由方法的调用者负责还是由接口方法本身负
责,缺省是由方法调用者负责。(1.42+)
说明:对于模块间接口方法的参数的合法性检查这一问题,往往有两个极端现象,即:要么是调用者和被调用者对参数均不作合法性检查,结果就遗漏了合法性检查这一必要的处理过程,造成问题隐患;要么就是调用者和被调用者均对参数进行合法性检查,这种情况虽不会造成问题,但
Page 15 , Total 19