金蝶EAS BOS开发规范，也可作为java的开发规范(三)

 

1.  方法规范

1.1.  概述

方法是Java程序的基本功能单元，其重要性不言而喻。函数设计的细微缺点很容易导致该函数被错用，所以光使函数的功能正确是不够的。

1.2.  方法内部实现的规则

不同功能的方法其内部实现各不相同，看起来似乎无法就“内部实现”达成一致的观点。但根据经验，我们可以在方法体的“入口处”和“出口处”从严把关，从而提高方法的质量。

·  在方法体的“入口处”，对参数的有效性进行检查。

很多程序错误是由非法参数引起的，我们应该充分理解并正确使用“断言”（ assert ）来防止此类错误。

良好的编程典范规定：当编写一个 方法 时，必须验证所有传递进来的参数，如果任何一个参数不合乎要求，就应当明确地引发一个异常，而在基类库中定义有大量的异常类，所以可以轻而易举地使用其中的一个。

·  在方法体的“出口处”，对 return 语句的正确性和效率进行检查。

如果方法有返回值，那么方法的“出口处”是 return 语句。我们不要轻视 return 语句。如果 return 语句写得不好，方法要么出错，要么效率低下。

1.3.  返回值的规则

·  不要省略返回值的类型。

如果方法没有返回值，那么应声明为 void 类型。

·  方法名字与返回值类型在语义上不可冲突。

1.4.  注意事项

　　1. 方法的规模尽量限制在200行以内。 

　　2.一个方法最好仅完成一件功能。 

　　3.为简单功能编写方法。 

　　4方法的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。 

　　5.尽量不要编写依赖于其他方法内部实现的方法。 

　　6.避免设计多参数方法，不使用的参数从接口中去掉。 

　　7.用注释详细说明每个参数的作用、取值范围及参数间的关系。 

　　8.检查方法所有参数输入的有效性。 

　　9.检查方法所有非参数输入的有效性，如数据文件、公共变量等。 

　　10.方法名应准确描述函数的功能。 

　　11.避免使用无意义或含义不清的动词为方法命名 

　　12.方法的返回值要清楚、明了，让使用者不容易忽视错误情况。 

　　13.明确方法功能，精确（而不是近似）地实现方法设计。 

　　14.减少方法本身或方法间的递归调用。 

2.  异常处理规范

下面的规则概括了引发和处理错误的指南： 

·  所有导致异常的代码路径都应提供一个不用引发异常就能检查是否成功的方法。例如，要避免  FileNotFoundException ，可调用  File.Exists 。尽管这并不总是可能的，但其目标是在正常执行情况下不应有异常发生。 

·  不要直接从基类 Exception 派生新异常。

·  在每个异常中使用本地化描述字符串。当用户看到错误信息时，该信息将从引发的异常的描述字符串派生，而不是从异常类派生。 

·  以编程方式创建正确的错误信息（包括标点符号）。异常的描述字符串中的每个句子都应该以句号结束。以一般方式向用户显示异常消息的代码不必处理开发人员忘记最后面的句号的情况。 

·  为编程访问提供异常属性。仅当存在附加信息有用的编程方案时，才在异常中包含附加信息（不包括描述字符串）。很少需要在异常中包含附加信息。 

·  对于正常或预期的错误，或者对于正常的控制流，不要使用异常。 

·  类的设计应使在正常使用中从不引发异常。 

·  如果传递或检测到无效参数，引发 象 Argument Invalid Exception 这样的 的异常 或者其他的已错误代码构造的应用程序异常。  

·  引发最特定的可能异常。 

·  针对开发人员，为异常创建有意义的消息文本。  

·  在引发异常时清理任何副作用。当异常从函数引发时，调用方应该能够假定没有副作用。例如，如果  Hashtable. put  方法引发异常，则调用方可以假定指定的项没有添加到  Hashtable 。

·  需要细化的问题：

异常处理体系的建立

error code 的分配规则定义

异常处理与 log 的 关系

包顶级的异常类的建立

  等等的此类问题。

3.  性能

现在的计算机性能已经大大超过从前了，对一个没有特殊要求的应用来说足以满足需要。但当我们在程序的正确性、坚固性、清晰性都良好的同时，为何不把程序弄的更快一些呢？也许，现在你多思索一下，以后的产品就会少许多力气调整性能。以下从几个方面阐述关于性能的优化。

3.1.  瓶颈

对于下一代产品，网络带宽成为了一个程序运行效率的当然瓶颈问题。

因此，要求我们对程序中的查询做优化处理。一般情况下，除非做统计，否则默认情况下对数据量非常大的表或视图（关联）都要求有条件地进行，并且过滤的条件越细越好。这会大大降低网络流量。

3.2.  代码调整

收集公共表达示和计算：

如果一个代价昂贵的计算或查询多次出现，那么就只在一个地方实现，并记录结果。这样会避免无谓的重复计算与查询工作。

3.3.  不要在循环中构造和释放对象

3.4.  使用 StringBuffer 对象

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

3.5.  避免不必要的使用关键字 synchronized

这是一个避免死锁的好方法

3.6.  减少对变量的直接访问

对数据的封装原则应该规范化，不要把一个类的属性暴露给其它类，而是应该通过访问方法去保护他们。如果某个属性的名字改变，你只需要修改它的访问方法，而不是修改所有相关的代码。

3.7.  减少对象的创建

JAVA中创建对象的开销很大，对程序中频繁使用的对象，可将其缓存起来，下次使用时直接从缓存中获取对象。

4.  质量保证

·  1.在软件设计过程中构筑软件质量。 

　　代码质量保证优先原则 

　　（1）正确性，指程序要实现设计要求的功能。 

　　（2）稳定性、安全性，指程序稳定、可靠、安全。 

　　（3）可测试性，指程序要具有良好的可测试性。 

　　（4）规范/可读性，指程序书写风格、命名规则等要符合规范。 

　　（5）全局效率，指软件系统的整体效率。 

　　（6）局部效率，指某个模块/子模块/函数的本身效率。 

　　（7）个人表达方式/个人方便性，指个人编程习惯。 

·  2.只引用属于自己的存贮空间。 

·  3.防止引用已经释放的内存空间。 

·  4.过程/函数中申请的（为打开文件而使用的）文件句柄，在过程/函数退出前要关闭。 

·  5.认真处理程序所能遇到的各种出错情况。 

·  6.系统运行之初，要初始化有关变量及运行环境，防止未经初始化的变量被引用。 

·  7.系统运行之初，要对加载到系统中的数据进行一致性检查。 

·  8.严禁随意更改其它模块或系统的有关设置和配置。 

·  9.不能随意改变与其它模块的接口。 

·  10.充分了解系统的接口之后，再使用系统提供的功能。 

·  11.要时刻注意易混淆的操作符。当编完程序后，应从头至尾检查一遍这些操作符。 

5.  通用类开发

5.1.  概述

写出一个正确有效运行的软件是很困难的。因此，当某个程序（或模块、甚至类、函数）在一个地方运行的很好时，我们希望它能在别的地方被使用。

5.2.  多语言处理规范

多语言处理包括Web界面开发、GUI界面开发、业务逻辑组件开发、数据库设计几个方面。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/715744/viewspace-202022/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/715744/viewspace-202022/