1.在switch块内，每个case通过break/return等终止，或者说明继续执行到那个case为止。每个switch块内，必须包含一个default语句且放在最后。即使什么没有。
2.if/else/for/while/do语句中必须使用大括号，即使一行代码
3.表达异常的分支时，少用if-else
可以使用
if(condition){
.. return obj;
}
如果非要使用，勿超过3层。超过三层可以使用卫语句、策略模式、状态模式等实现
4.除常用方法（getXXX isXXX）等外，不要在条件判断中执行其他复杂语句，提高可读性
5.循环体中语句要衡量性能，尽量移至循环体外处理（如定义对象、变量、获取数据库连接，进行不必要的try-catch操作）
6.做批量操作的接口，接口入参保护。
7.参数校验
1）调用频率低的方法
2）执行时间开销很大的方法
3）需要极高稳定性和可用性方法
4）对外提供的开放接口，（如RPC/API/HTTP接口）
5）敏感权限入口
8.不需要参数校验
1）可能被循环调用的方法，方法说明外部参数检查要求
2）底层调用频度高的方法 例如DAO参数校验
3）声明private方法，只会被自己调用的方法
补充--引自http://www.cnblogs.com/huahua035/p/6905504.html
工作中很少提到“入参保护”这个词，更多的是“参数校验”的说法；谈下个人对接口入参保护的理解：
1、接口入参保护，“保护”的是服务端应用，即接口提供方，最常见的做法就是校验入参的有效值范围和设置批量操作白名单；比如，接口入参中包含日期时，校验日期必须在N天范围内，或者请求返回的记录总数必须在X条以内（比如10W条，否则缩小请求查询的记录范围），或者请求返回的记录必须分页查询返回；
开发手册中，尤其提到的场景就是批量操作，因为批量操作非常耗时耗资源（服务端），批量操作的批量数应该有上限，而不是无限的。假如客户端请求一次批量操作10W笔转账订单，服务器应该果断拒绝，很不是很SB的忠实执行，会对服务端造成严重影响的批量请求，服务器端应做好保护性编程，必要时应直接失败，并在Result中返回明确的errorCode和errorMsg;而且，对应批量操作，实际应用中还会配置批量操作白名单！
2、入参保护，一般都是通过卫语句实现：if（请求记录>10000条） return；直接返回。