代码规范浅谈

摘要:代码规范这东西网上很容易百度到一堆,除了天下文章一大抄的问题,另外,多数只给了结果,原因没有充分说明,或者非常的纠结于大写小写,一个函数可以写几行的细节。感觉有点容易让新人误入歧途


代码规范这东西网上很容易百度到一堆,除了天下文章一大抄的问题,另外,多数只给了结果,原因没有充分说明,或者非常的纠结于大写小写,一个函数可以写几行的细节。感觉有点容易让新人误入歧途。

于是锅叔打算根据自己的经验分析下这些规范产生的原因,帮助新人深入理解为什么这么规定,知其然并知其所以然。

一、“代码规范”的由来

工作中如果你没怎么接手过其他同学的代码,那肯定会比接手过离职同学的代码,经常帮其他同学排查Bug的“大牛”们对 代码可维护性 的理解,要差上一个数量级。

如果你没怎么参与过一个持续存在3-5年以上,需求变更频繁的系统模块的迭代开发,你也不容易理解, 代码重构 对于一个稍作修改,就Bug此起彼伏的模块质量改善的重要意义。

对软件的迭代效率和质量负责任的人通常就是Team Leader,PM,这类第一责任人,他们深思熟虑一番后,得出一个重要结论,上面这些难于交接,修改困难,Bug横行的坑,很大程度上都跟代码写的不 规范 有关,因此就编写了 代码规范。

二、代码规范作用

程序员的本质也是个手艺人,与大部分其他行业的施工规范的作用相似,主要是作用是

1. 避免造成施工缺陷,提供施工质量。

2. 方便同行交流,以便后期维护。

举个例子,锅叔家中近来正好在装修,因为不是从毛坯重头装修的,这样一些水电的走线情况就不是很清楚了,是装修前已经施工完毕的。理论上开关插座线路是可以随意的铺设的,只要联通就可以,可以一会儿排成一字,一会儿排成人字。这时比如你需要在墙上挂一副画或者镜子,需要在墙上打孔固定,那这个孔会不会打穿墙内的水电线就非常随缘了。安装师傅只能根据布线规范和经验判断,一般的电线布线在墙面是横平竖直的,不会斜着来,或者转圈圈,水管一般走天或者走地。你也就只能祈求之前施工的水电师傅是遵循这个规范来的,如果他走线很有个性导致你打坏了线路要重新维修,你一定会在心里问候他的。

三、代码规范的内容

实践中代码规范的内容很多团队应该是“借鉴”来的。锅叔其实建议,借鉴了之后,还要重视后期的调整,补充。每个团队的技术栈,项目特点会有不同,在编程上的关注点也会对应不同。代码评审不应简单的以规范为准,而应该以提高可维护为目的。评审中发现而未在代码规范中包含的内容,要及时增补。同时评审时还要注意传达规范的目的,而不仅是让大家机械遵守。

下面是一些锅叔觉得比较常见重要的,做一下简单解释说明,排名不分先后 。

1. 不要使用魔法数字

可读性,自己体会

if(deviceState == 1){
     doSomeThing();      
}
//对比
if(deviceState == DEVICE_STATE_ON){
     doSomeThing();      
}

2. 方法不要太长,注意分层,隐藏细节

合理分层,自行体会

function A(){
      买菜();
      备菜();
      炒菜();
}    

vs

function B(){
      ……
    下楼;
      打开车门;
      按下点火开关;   
      打左转向灯;
    鸣笛;
      开出车位;
    如果遇到隔壁老王就打个招呼;
    出小区右转;
    第二个十字路口左转; 
      进菜市场左转第一个摊位,买两斤黄瓜;
    拿上黄瓜,步行回车上;
    扫码交车费; 
    …………
}

3. 变量,方法命名要有准确含义

function A(){
    if(a == 1){
        B();
    }else{
        C();  
    }  
}    
//VS
function 送礼物(){
    if(用户性别 == 男){
         送茅台();
     }else{
         送古驰();
     }          
}

4. 无效的逻辑要及时清理

懒得举例了,自行体会

5. 方法的功能应当与命名对应,不做超出命名范围的动作

送礼物 方法,做了他命名之外的事,很容易被调用的人错误使用

function 收礼不办事举报(){
    送礼物();
    if(不办事 并且 不是我干爹){
         举报他();
    }
}
//VS  
function 送礼物(){
    if(用户性别 == 男){
         送茅台();
     }else{
         送古驰();
     } 
     
     if(不办事){
       举报他();  
    }         
}    

6. 用户操作的错误,要确保有错误反馈。

典型的如没有数据和发生错误,无法返回数据是不同情况,要加以区别。


7. 系统错误应当有日志

错误要写日志, 不至于死无对证。。-_-|| 

8. 耗时操作要界面进行异步等待处理

让用户知道,现在正在处理,不是系统故障了。


9. 业务列表查询需要进行分页处理

当数据记录上亿时,一次全部取出,放入内存,可能会使服务器宕机……

10. ………………

作者:锅叔
原文链接:https://www.cnblogs.com/uncleguo/p/16143561.html


本文内容仅供个人学习、研究或参考使用,不构成任何形式的决策建议、专业指导或法律依据。未经授权,禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载,请保留原文来源信息,不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持!

链接: https://shenqiku.cn/article/FLY_11351