一、规范目的：
规范的目的是提高代码可读性，阅读的舒适性，减少维护的成本，方便后续运维，让运维人员看到别人写的代码就像自己写的代码。随着需求的增加，代码必然是越堆越多，越来越乱，最后失控导致项目腐烂。物理学上的熵让我们理解了一件事，如果不施加外力影响，事物永远向着更混乱的状态发展。比如，房间如果没人打扫，只会越来越乱，不可能越来越干净。
二、规范要点
1.局部变量首字母小写(Camel)，全局变量统一加下划线开头。
- 全局变量统一加下划线
- 局部变量首字母小写
2.格式化规范
为了可读性，所有的代码必须格式化。
- 错误示范：
中间不要出现无效的空格，影响代码可读性。
- 正确示范：
3.枚举的规范
- 错误示范：
- 正确示范：
4.命名规范
命名规范遵循原则：
- 简单
- 可读
- 统一
规范是需要成本的。
要做到这三个方面，仅仅是靠规范文档是很困难的。大家对简单，可读，统一的理解各不相同，最后生成的代码必然是千人前面，所以必须引入代码审查机制。理论上需要对业务的深入了解，需要有很好的英文功底，编程功底的人来做代码审查是最优选 。
流程：可操作的规范文档定制和讨论==>核心模块的命名拟定和讨论==>资深开发人员的代码审查==>
4.1常用变量名称要统一命名。
返回是否成功命名：isSuccess
1)局部变量第一个字母统一小写
2)是否成功统一下：isSuccess
- 错误示范：
- 正确示范：
4.2上层模型命名和底层数据模型保持一致
严格按照DB模型为指导命名，保证整体系统的命名一致性，方面后续运维良好的代码可读性。
- 错误示范：
该接口是消息回复，这里的注释和命名都是不对的。Replay已经在DB模型出现过，所以必须和DB模型命名保持一致，不能自己另外命名。注释必须准确，新增消息的注释和另外一个add接口重复
4.3画蛇添足
DB命名画蛇添足，违背了简单原则
- 错误示范：
4.4不要使用语焉不详的数字
- 除了SQL，尽量不要使用可读性不好的数字。
4.5复杂不可读紊乱命名
- 错误示范
UserLogin不如LoginaddUser和其他命名大小写不一致CountryLogo和其他两个命名结构不一致，一个是名词，一个是动宾结构。
5.其他细节规范
- 错误示范：
- 正确示范：
6.代码审查
- 负责人审查
- 小组讨论会
规范的关键是审查，否则必然会变成形式。引入审查就意味着成本，对中小团队来说一个月可能一次就足够了。