java编码规范

1.一个包中类的数量不要过多，否则应该建立新的包，类的名字应该与包的名字保持某种意义上的一致

2.一个类不应该太长，否则不利于其他人阅读，我的经验是保持两编辑器屏幕的代码行数，六个方法以内

3.一个方法不应该太长，30行以内为妙，不要超过50行，最多不要超过一编辑器屏幕，否则别人在读你的代码时会感觉到畏惧，让别人一看就懂的代码，有利于后期的维护成本与同事之间的交流

4.如果可以的话，一个方法的参数个数不要太多，我的经验不要超过3个，再多的话不利于别人的理解

5.如果一个条代码的宽度超过了编辑器的宽度，可以折行，否则尽量不要折行，无论是调试的时候打断点还是别人看你的代码，都会不方便

6.如果可以，循环变量名尽量不用i、j、k，尽量见名知义，比如startIdx，endIdx，foundIdx等等

7.代码尽量用短句，不用长句，尽量用简单句，不用复杂句，这样别人看你的代码会很容易理解，很容易维护，故意将代码写的很复杂只能增加理解的难度和时间，对个人的程序还好，但对于大型程序，还是简单为好，简单即美，短小即美

8.暂时用不到的代码一定记得要删掉，不要仅仅注释，因为有svn版本控制呢，越是晚删掉这些被注释的代码，顾忌越大，可能到最后谁也不敢轻易删掉，因为谁都想这些无用代码是不是有什么很重要的作用，还容易造成代码混乱

9.把注释写详尽确实是不错的注意，但不要把一些没用的，可有可无的，显而易见的东西都写上，还有像什么时间，作者之类都应该去掉。描述一个类，一个方法的用途是什么，如果有重点或者难点代码，可以指出来。再有就是参数，如果参数可以做到见名知义，就无需再增加参数的注释，加注释时一定要记得不要影响代码的可读性和美观

10.无论是大模块，还是小模块，一定记得要提炼公共代码，要么用Util之类的工具类采用静态方法，要么用Helper之类的辅助类采用spring注入。切记：公共代码的优点是一改全改，而这也可能会成为它的缺点，修改代码时一定记得寻找有多少个地方引用了此公共代码

11.在使用if else条件分支判断时，最好关闭最后的else子句，因为它可能对当前版本不会有什么问题，但是在下个版本的修改过程中很容易被遗忘而出错

12.如果一个方法的输入参数需要校验，如果可以的话，最好将校验的代码统一提取出来，形成Util工具类，或者采用断言的机制，这样可以很大的减少代码量，否则若方法带了太多的校验代码，势必会影响代码的阅读，而且若是校验规则需要更改的话，还得逐个更改，出错的概率便会增大。或者干脆将代码校验作为一个横切关注点，采用spring或者其他aop工具对所有需要进行校验的类进行横切也不错。例如：

class TestClass{
    public void method(String name) {
        if (Util.isNotNull(name)) {
        }
        //or
        Assert.isNotNull(name, "name can not be null");
    }
}
class Assert{
    public static void isNotNull(String str,String info){
        if(str==null){
            throw new IllegalArgumentException(info);
        }
    }
}
class Util{
    public static boolean isNotNull(String str){
        if(str!=null){
            return true;
        }else{
            return false;
        }
    }
}

13.项目组应该将文档与代码看做一个整体，他们同样重要，在文档中用项目组程序可以理解的方式描述当前程序最新版本的功能与状态，包括代码难点，保持两者的同步更新，将很大程度上减少项目维护时间，可以让其他程序在没有代码开发者的情况下快速找到问题的原因，应将文档看做是与代码同样重要的地位而不仅仅是代码的补充

14.变量使用最后紧跟在变量声明之后，两端代码行之间最好不好放置其它代码行，以导致代码逻辑不清晰。例如：

       List list=...;
       Map map = new HashMap();
       map.put("name", "talong");
       map.put("age", "30");
       ...
       for(int i=0;i<list.size();i++){

       ...

       }

14.如果一个方法具有很强的流程性质，请务必将其中每一步流程的操作代码提取出来形成公共代码，这样可以极大的简化流程控制代码，对于后期的修改很有益处

15.很多公司的项目组都没有培训，甚至连个开发规范文档都没有，即使有相关的培训也是草草了事，开发新人通常听到的话是“对于很多问题不能解释清楚，还是等到具体的业务具体的问题的时候再说吧，有不会的问题就问”，这只能说明项目组不懂得进行文档及项目开发方面经验的积累，若是能对新人进行系统的培训及业务介绍，特别是对编码规范进行严格的控制，必定能后期的开发大有益处，我相信这也是公司文化积淀的一部分

16.有时候在开发的过程中，我们会有意或者无意的做大量的假设，比如某某变量不可能为null或者不可能为空（比如：数据库中取得由别人进行维护，或者由其他人的程序进行传递），这样就造成很多时间，我们在使用一个对象的时候不会去进行校验null和空，而且有时候会感觉写大量的校验让程序看起来十分的不爽，但是姑且不说这样是否真的能满足当前的大部分测试案例，如果后期程序设计变动，尤其是当其他开发部门也发生需求的变动，出错的几率就会非常大

17.对于程序命名问题，诸如变量名，函数名，类名，页面中的标签名，常量名，代码缩进（包括控制结构的括号缩进），注释格式，注释内容等等，都需要进行详细的文档化说明，并需要严格的执行，这样对于代码的审查和后期的维护都非常有好处

18.对于boolean表达式，尽量避免采用！运算符，最好还是采用expression==true 或者expression==false的语句，让别人一看就知具体逻辑，有的开发人员将bool表达式写的过分复杂，导致过了一段时间连自己再看自己的代码都要反复推敲几遍，这样非常不利于程序的维护

19.适当减少ifelse嵌套的层次，能很大程度上减轻代码的理解难度

20.数据库表字段的备注信息，类的核心功能，方法的功能以及参数意义，所有这些都要写上注释，没有注释最好不要提交版本控制

21.如果你是开发组长，那么在开发人员中采用一样的编码规范是非常有意义的

22.开发组长和技术骨干更可能会站在项目的全方位来思考，竟可能注意到代码中的常用方法，常用类等，将他们进行提炼以利于大家共用是非常必要的，时间就了可以形成自己的工具类库。这样的类库用的多了，经过长时间的考验，出现bug的几率也会很低

后续中。。。