码出优美

  一份拥有良好可读性和拓展性的代码是项目里的良药,它不仅看着舒服,改起来也方便,甚至还能重用,各模块逻辑分明。“见码知功底”,而要达到高手那种简洁有力的境界,需要进行大量的总结和练习,今天我们就来谈谈如何写出优美的代码。

  

命名

  好的命名应该具有如下特征:

  1,意思正确。这是最基本的要求,不要挂羊头卖狗肉,词不达意,要一眼就知道什么意思。就算一眼看不出来,复制到有道词典翻译一下也能知道什么意思;

  2,单复数分明。如果是一个数组,要么加s/es结尾表明其是复数,要么加入list表示它是一个数组。如cars,carList都可以表达一个车的列表;

  3,慎用缩略词。缩略词可以让我们的命名更加简洁,但是一!定!要!是!业!界!通!用!缩!略!词!比如info原意为information,msg原意为message,fn原意function,conf原意config等等,这些缩略词都是业内传统了,大家都知道什么意思,切记不要自己乱造缩略词;

  4,有具体含义。根据业务场景去命名,而不是根据抽象命名;比如getUnreadMsgList,一看就知道是获取未读消息列表的意思,而getData这种说了跟没说一样,缺乏具体含义。

 

注释

  有表达力的代码是不需要注释的。比如一个init函数,一看就知道是用于做一些初始化的工作,没必要写多余的注释来说明。

  但是有一些场景注释是非常有必要的,下面几种场景要添加注释:

  1,一些针对特殊业务场景而订制的特殊逻辑。比如当我们更新个人信息的时候,由于后端的问题,需要少传一个诸如生日的信息,或者更新头像时要多传一个时间戳来供其他业务以后使用。这些莫名其妙的增删属性,如果不加以注释,将导致后续自己都无法理解;

  2,可能会出现隐患的代码。由于自身水平所限,或者本身技术上就无法实现,只能通过一些特殊技巧来仿制一些效果,往往会存在安全隐患,比如:用户操作太快会出问题,网络太慢会出问题,某个接口调不通这页面会全挂了,一些特殊的操作会引起的暂时无法解决的bug等等场景,都需要注释说明;

  3,涉及到某些高深的或者生僻的技术知识。这种也要注释,以提醒自己和其他开发者。

  一般来说,注释基本上都是在表达“这里我为什么这么做”,很少有注释会去表达“我是一个什么玩意儿”,如果是后者的注释,只能说明命名没做好。

  

函数

  函数是代码的灵魂,也是写逻辑的载体,以下几个要求是判断一个开发者函数写的好不好的标准。

  1,是不是单一职责。一个函数应该只做一件事,而这件事应该能通过函数名就可以清晰的展示。这是一个非常好的特性,一个辣鸡的函数可能动辄几百行代码,各种逻辑堆积在一起,看得人头脑发晕,甚至开发者自己都理不清楚;判断这个函数是不是单一职责的技巧很简单:看看它还能不能再拆分。

  2,有没有层级之分函数与函数之间是有身份地位之分的,有负责整体大局观的高级函数,也有专注细节的打工仔低级函数。如果不建立起层级结构,就容易迷失在细节的海洋里。比如:

  

 

 

  对于做一顿饭这个函数来说,他不需要关心诸如买菜时反复挑选这种细节,它只需要知道,大概有三个大步骤就行了。所以这段逻辑会根据其地位拆分出不同等级的函数,假设没有层级之分,那么从第一步的“搭公交”一直写到最后一步的“倒垃圾”,这东西会变得极难维护。

 

  3,承载的场景是否足够简单。有时候我们会遇到这样一种场景:一个函数在很多地方都会用到,但是不同地方传入的参数不一样,这样我们为了函数的通用性,就针对入参做了很多种场景的识别,导致入参非常多,里面还需要根据不同的场景做逻辑上的细微调整。所以单单是取传入参数都够呛了,一堆的if else或switch case。

  这个函数太难了,而且这已经违背了函数的单一职责原则,它在里面做了多种场景的判断,从而表现出不同的行为,但这些行为又不是完全不同,而是“大体相同”,如果重写好像又会增加很多的重复的代码。解决的方法是做更小粒度的拆分,将那些真正与业务脱钩的部分抽离出来,而不同场景对应不同的处理函数,刚刚抽离的业务脱钩函数正好作为这些不同场景函数公共部分!

 

posted @ 2019-11-16 17:56  陌上兮月  阅读(...)  评论(... 编辑 收藏