正例：
StringBuffer sb = new StringBuffer(); //超过 120 个字符的情况下，换行缩进 4 个空格，并且方法前的点符号一起换行 sb.append("zi").append("xin")... .append("huang")... .append("huang")... .append("huang");反例：
StringBuffer sb = new StringBuffer(); //超过 120 个字符的情况下，不要在括号前换行 sb.append("zi").append("xin")...append ("huang"); //参数很多的方法调用可能超过 120 个字符，不要在逗号前换行 method(args1, args2, args3, ... , argsX);关于换行Google并没有给出明确的要求，而阿里巴巴则给出了强制性的要求。Google特别提示通过一些重构手法可以减少单行字符长度从而避免换行，这一点我颇为认同。关于参数很多的方法调用超过120个字符需要换行时，这暴露除了过长参数列的代码坏味道，解决方式之一就是使用重构手法的Replace Parameter With Method的方式把一次方法调用化为多次方法调用，或者使用Introduce Parameter Object手法创造出参数对象并进行传递。
17. 【推荐】循环体内，字符串的联接方式，使用 StringBuilder 的 append 方法进行扩展。 反例：
String str = "start"; for (int i = 0; i < 100; i++) { str = str + "hello"; }说明：反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象，然后进行append 操作，最后通过 toString 方法返回 String 对象，造成内存资源浪费。
这是《Effective Java》以及其他文章中经常提及的优化方式，而且面试初级Java工程师时几乎是一个必考点。其实不仅是在循环体内，而是所有需要进行多次字符串拼接的地方都应该使用StringBuilder对象。
20. 【推荐】类成员与方法访问控制从严：
1） 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。
2） 工具类不允许有 public 或 default 构造方法。
3） 类非 static 成员变量并且与子类共享，必须是 protected。
4） 类非 static 成员变量并且仅在本类使用，必须是 private。
5） 类 static 成员变量如果仅在本类使用，必须是 private。
6） 若是 static 成员变量，必须考虑是否为 final。
7） 类成员方法只供类内部调用，必须是 private。
8） 类成员方法只对继承类公开，那么限制为 protected。
说明：任何类、方法、参数、变量，严控访问范围。过宽泛的访问范围，不利于模块解耦。思 考：如果是一个 private 的方法，想删除就删除，可是一个 public 的 Service 方法，或者一个 public 的成员变量，删除一下，不得手心冒点汗吗？变量像自己的小孩，尽量在自己的视线内，变量作用域太大，如果无限制的到处跑，那么你会担心的。
这其实就是经典的原则‘ Principle of least privilege’ 的体现。我们必须遵循这一原则，但不知为何阿里巴巴将其级别列为“推荐”。
7. 【参考】方法中需要进行参数校验的场景：
1） 调用频次低的方法。
2） 执行时间开销很大的方法，参数校验时间几乎可以忽略不计，但如果因为参数错误导致 中间执行回退，或者错误，那得不偿失。
3） 需要极高稳定性和可用性的方法。
4） 对外供的开放接口，不管是 RPC/API/HTTP 接口。
5） 敏感权限入口。
8. 【参考】方法中不需要参数校验的场景：
1） 极有可能被循环调用的方法，不建议对参数进行校验。但在方法说明里必须注明外部参 数检查。
2） 底层的方法调用频度都比较高，一般不校验。毕竟是像纯净水过滤的最后一道，参数错 误不太可能到底层才会暴露问题。一般 DAO 层与 Service 层都在同一个应用中，部署在同一 台服务器中，所以 DAO 的参数校验，可以省略。
3） 被声明成 private 只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参 数已经做过检查或者肯定不会有问题，此时可以不校验参数。
编写代码时，对参数进行校验是不可避免的。详细说又扯到“防御式编程”和“契约式编程”的话题上。这两项之所以列为参考，并没有强迫大家遵守。
6. 【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
反例：“TCP 连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。
看到这一条我已经笑出来了。这一条说的很好，注释是用来阐述问题的，如果看了注释还一头雾水，那么这样的注释不要也罢。使用中文没什么可丢人的，解决问题才是王道。
7. 【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后， 就失去了导航的意义。
阿里巴巴对该条的说明非常到位。其实我们团队在编写代码时默认是没有任何注释的，因为我们追求的是self-explanatory methods。即代码本身已经就能说明它的用途。只有在很少的情况下需要添加注释。
编程规约的第九部分都是很好的tips，值得去了解和学习。
除了编程规约之外，日志规约、MySQL规约、工程规约和安全规约也都有极高的参考价值，这也是比Google的Java Style Guide出色的地方。这里就不再评述了。
阿里巴巴公布这个Java开发手册绝对是值得赞赏的事情。最后我也想给其提几点建议：
建议使用公开wiki的方式发布该手册，而不是采用pdf的方式。因为如果像google那样是公开wiki的方式的话，可以很方便大家参与修正和改进，并且可以看到版本历史。
该手册并没有明确的版权许可，只是在页脚处加入了“禁止用于商业用途，违者必究”的字样。Google的style guide的版权为CC-By 3.0 License，建议阿里巴巴能够指明其版权。
相关文章
精彩导读
热门资讯
关注我们
