现代软件架构都需要协同开发完成，高效协作即降低协同成本，提升沟通效率，所谓无规矩不成方圆，无规范不能协作。

        众所周知，制订交通法规表面上是要限制行车权，实际上是保障公众的人身安全。试想如果没有限速，没有红绿灯，谁还敢上路行驶。对软件来说，适当的规范和标准绝不是消灭代码内容的创造性、优雅性，而是限制过度个性化，以一种普遍认可的统一方式一起做事，提升协作效率。

        代码的字里行间流淌的是软件生命中的血液，质量的提升是尽可能少踩坑，杜绝踩重复的坑，切实提升质量意识。

手册大纲

今天在这里我们只对编程规约进行学习探讨

---

命名

起名字是项目当中非常麻烦的事，对于英语不好的同学，往往为了省事，随意命名，这样不尽让代码难以理解，也给后期的维护造成了麻烦。

方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格

例如 ：  localValue / getHttpMessage() / inputUserId

属性命名

POJO 类中布尔类型的变量， 都不要加 is 前缀 ， 否则部分框架解析会引起序列化错误。例如在定义为基本数据类型 Boolean isDeleted； 的属性，它的方法也是 isDeleted() ， RPC框架在反向解析的时候，“误以为”对应的属性名称是 deleted ，导致属性获取不到，进而抛出异常。

---

接口和实现类的命名

对于 Service 和 DAO 类，基于 SOA 的理念，暴露出来的服务一定是接口，内部的实现类用 Impl 的后缀与接口区别。

例如：UserServiceImpl 实现 UserService 接口。

---

常量

首先你不是一个人在战斗，写成常量方便队友理解；

然后可以避免一些错误，无论是数字还是字符串常量，都可能在不同的地方拼写不一致，导致错误；

还有就是方便修改，比如你有100个地方用这个常量，只改一处就可以；

最后就是对你自己也好，几个月过后可能你想不起来这个常数是什么含义了。( ╯□╰ )

---

方法命名

应该直观明了，风格统一

1 ） 获取单个对象的方法用 get 作前缀。

2 ） 获取多个对象的方法用 list 作前缀。

3 ） 获取统计值的方法用 count 作前缀。

4 ） 插入的方法用 save/insert 作前缀。

5 ） 删除的方法用 remove/delete 作前缀。

6 ） 修改的方法用 update 作前缀。

---

equals

1 ） Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals 。

2 ） 所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。

---

数据类型

1 ）所有的 POJO 类属性必须使用包装数据类型。

2 ） 所有的局部变量使用基本数据类型。

---

构造方法

构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中