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