代码规范值钱吗？分享内部不成熟的代码规范做法。

一、规范目的：

规范的目的是提高代码可读性，阅读的舒适性，减少维护的成本，方便后续运维，让运维人员看到别人写的代码就像自己写的代码。

随着需求的增加，代码必然是越堆越多，越来越乱，最后失控导致项目腐烂。

物理学上的熵让我们理解了一件事，如果不施加外力影响，事物永远向着更混乱的状态发展。比如，房间如果没人打扫，只会越来越乱，不可能越来越干净。

二、规范要点

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.代码审查

• 负责人审查
• 小组讨论会

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