一、规范目的：

规范的目的是提高代码可读性，阅读的舒适性，减少维护的成本，方便后续运维，让运维人员看到别人写的代码就像自己写的代码。
随着需求的增加，代码必然是越堆越多，越来越乱，最后失控导致项目腐烂。
物理学上的熵让我们理解了一件事，如果不施加外力影响，事物永远向着更混乱的状态发展。比如，房间如果没人打扫，只会越来越乱，不可能越来越干净。

二、规范要点

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不如Login
addUser和其他命名大小写不一致
CountryLogo和其他两个命名结构不一致，一个是名词，一个是动宾结构。

5.其他细节规范

  • 错误示范：
  • 正确示范：

 6.代码审查

  • 负责人审查
  • 小组讨论会
　　规范的关键是审查，否则必然会变成形式。引入审查就意味着成本，对中小团队来说一个月可能一次就足够了。
 

版权声明：本文为jackyfei原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/jackyfei/p/11933600.html