Jackyfei

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

一、规范目的:

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

二、规范要点

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

  • 负责人审查
  • 小组讨论会
  规范的关键是审查,否则必然会变成形式。引入审查就意味着成本,对中小团队来说一个月可能一次就足够了。
 
希望以上分享对你有所帮助,感谢您的捧场。
作者: 张飞洪[厦门]
我的视频:ABP vNext视频系列
QQ群: 共享交流群

打赏支持

posted @ 2019-11-27 09:12  张飞洪[厦门]  阅读(570)  评论(0编辑  收藏  举报