Java编程规范的心得
听了子柳讲的Java编程的规范，“这里每一个规范都有淘宝开发人员一段悲惨的经历，这是一部开发人员的血泪史”——子柳（百技大学的校长）。鉴于测试部门目前也要编写ruby脚本和进行webx测试，为了避免我们测试人员重蹈开发人员的覆辙，我把一些可以通用的编程规范做了一下总结，希望对大家有些帮助。1. 在程序的分支和复杂的逻辑处写详细的注释
a) 代码特殊处理（比如特殊约定，类似字符串按一定规则组合或拆分，用List或Map返回不同类型对象，用事务时事务中返回的对象）的地方要注释
b) 在一些逻辑复杂或重要的代码中修改，建议加上作者，时间，注释
实例：
/**
* 根据类目ID找到主路径，并表示成两维数组，格式为：
* [根类目.ID, 根类目.名称], [类目X.ID, 类目X.名称], …[本类目.ID, 本类目.名称]。
*
* @param catPath
*
* @return String[][]
*
*/
String[][] getCategoryStringByPath(String catPath);心得：商品线业务一向比较复杂，而且业务逻辑更改比较频繁，所以在方法前加上这个方法测试的业务和当时的业务逻辑的概要介绍，这样在业务逻辑变更或这个业务已经删除时，可以直接找到修改或删除这部分测试代码，不要一段不需要或过时的代码一直保留在程序里，使代码越来越多，越来越不易读。
2.方法的注释中，参数的说明和返回值的说明要写详细
/**
* 检查字符串是否为null或空字符串”"。
*
* StringUtil.isEmpty(null) = true
* StringUtil.isEmpty(“”) = true
* StringUtil.isEmpty(” “) = false
* StringUtil.isEmpty(“bob”) = false
* StringUtil.isEmpty(“ bob “) = false
*
*
* @param str 要检查的字符串
*
* @return 如果为空, 则返回true
*/
public static boolean isEmpty(String str) {
return ((str == null) || (str.length() == 0));
}心得：这段代码只有一行，却加了8行注释，不仅交代了，这段代码做什么，还举了5个例子解释了程序内的具体是怎么判断的。这样其他的人员读到这段代码时就会很清楚的知道这个方法的功能是什么，减少读代码的时间。我们自己的测试脚本（比较复杂的）也可以借鉴开发的经验，为自己写的脚本加比较详细的注释，方便脚本维护和新人的使用。
3.避免无用的代码,没有无用的import,没有无用的成员变量,没有无用的private方法。
心得：这样可以减少代码或脚本的长度，增加代码的可读性。
4. 方法的参数不要超过5个，如果参数过多，使用对象包装（比如Query）
反例：
/**
* user can update the specified item, so prepare an DO and update database with that DO.
*
* @param vo – user submitted data
* @param sellerID – seller ID
* @param itemID – item ID
*
* @return -
*
* @link Result
*/
private Result updateItem(BidItemVO vo, String sellerID, String itemID, List lvo, String hasUpload, long limitCode) {}心得：上面这个反例一共有六个参数，第六个参数是有子柳加上去的，原因是参数太多都不知道根本不知道其他参数都做什么，有需要调用这个方法，传个参数到这个方法中，所以只有新加一个参数，造成这个方法的参数越来越多，这种情况下，需要使用参数包。
正例：
/**
* 为收藏夹项目提供基础数据 ruyue 2007-06-11
*
* @param String
* itemId, String dbRoute
* @return title id pictUrl ownerId price auctionType end props category
*/
public Result getAuctionDetail4Mercury(ItemDetailQuery query) {}5. 尽量避免类似“import java.io.*;”的引用
心得：这种import方式会把大量没有用的类加到程序中去，虽然现在的Eclipse比较聪明会自动识别要加载的类，并不会将所有的类加载，但是这是个不好的习惯，在写代码或脚本时要尽量避免。
6.太复杂的判断条件，比如有多个and、or的情况，加括号分类，分行。
心得：不管了不了解and和or优先级，判断条件太复杂时，应尽量加上括号，这样可以方便减少逻辑错误，增加代码的可读性，方便以后代码维护。
7. 合理使用常量，尽量避免出现硬编码（写死的）数字、字符串。
心得：不要将数字或字符串写到判断条件中，应尽量使用常量，并对这个常量注释，避免废弃很久的代码（由于没有人知道这个if语句到底是做什么的）仍然在程序中。
8. 在已有的类中增加方法，如果这个类不是自己创建的，建议加上作者，时间，注释。在已有的方法中加入条件分支或者其他业务逻辑，一定要注释。
/**
* 为收藏夹项目提供基础数据 ruyue 2007-06-11
*
* @param String
* itemId, String dbRoute
* @return title id pictUrl ownerId price auctionType end props category
*/
public Result getAuctionDetail4Mercury(ItemDetailQuery query) {}
if (ucBaseDO == null || ucBaseDO.isGradeNormal()) { // 加上如果是普通会员的话，要去取一下
// 商城VIP卡
if (user.isRegieUser()) {
// 取商城VIP卡 wanjian 2007.03.26
UserCardBaseDO mallVipCardDO = this.userCardManager
.findMallVIPCard(query.getLoginUserId(),
user.getUserId(), query
.getTrackNick());
if (mallVipCardDO != null) {
if (ucBaseDO == null) {
ucBaseDO = mallVipCardDO;
} else if (mallVipCardDO.getCurGradeIndex() > ucBaseDO
.getCurGradeIndex()) {
ucBaseDO = mallVipCardDO;
}
}
}
}心得：在别人创建的类或方法中加入自己的代码时，要在类的头部和修改的部分加入修改者的姓名，修改时间，注释。这样可以方便代码的维护，提高代码的可阅读性，尽快排查错误。
9. 资源的使用要及时释放。
心得：子柳分享的一个实例：不断地将用户信息put到一个map，但是从来没有将用户信息从这个map中清除，这样会造成内存越来越少，造成不可预估的后果。
10. ‘||’和’&&’操作中，代价小的，经常出现的情况先做判断。
心得：将代价小的先做判断，也许这个判断后，其他的判断就可以不用做了直接得到判断结果，这样可以节约开销。
11.测试类用到的参数最好放在每个方法内。
心得：这样便于每个方法单独测试。
12.要注意区别处理第一次进入edit页面和提交后校验失败返回edit页面，避免在提示出错的页面上面丢失输入数据。
心得：子柳分享了一个案例：第一次进入edit页面提交后校验失败返回edit页面，页面内非必选内容丢失。这个案例是很久以前的，目前我们的测试用例中已经覆盖这个问题，但是它还提醒我们业务流程中校验失败或操作失败后，重新编辑，修改或请求成功要注意查看是否有数据丢失或其他错误。
13. 合理地进行参数校验
a）Public类型的方法，在做业务处理之前，要保证传入的参数符合你的假设；
public boolean isMatchMD5(String source, String encodedStr) {
if (StringUtil.isBlank(source) || StringUtil.isBlank(encodedStr)) {
return false;
}
if (!CodesUtil.encodeMD5(source).equals(encodedStr)) {
return false;
}
return true;
}心得：“不要相信任何人传进来的参数”——子柳，Public方法很有可能被其他人调用，参数传递时很有可能传进来的参数不符合你的假设，所以在方法中必须加入参数校验。对于测试人员来讲要我觉得要“不要相信任何人传进来的参数包括自己”。
b）参数校验的顺序要合理，校验代价小的优先做
以上就是我在上《Java编程规范》课时总结出来也使用我们测试的一点规范，希望对大家的日常工作和编码有帮助。
转载务必注明出处Taobao QA Team，原文地址：http://qa.taobao.com/?p=8400