欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

码出优美

程序员文章站 2022-11-07 20:19:59
一份拥有良好可读性和拓展性的代码是项目里的良药,它不仅看着舒服,改起来也方便,甚至还能重用,各模块逻辑分明。“见码知功底”,而要达到高手那种简洁有力的境界,需要进行大量的总结和练习,今天我们就来谈谈如何写出优美的代码。 命名 好的命名应该具有如下特征: 1,意思正确。这是最基本的要求,不要挂羊头卖狗 ......

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

  

命名

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

  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。

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