最近买了本得到出的书<这就是软件工程师>,里面有几个行业大牛写的文章,其中一篇文章是<整洁代码:不是写出来的,而是读出来的>.
这篇文章说"不是写代码的人说自己的代码整洁就是整洁,而是读代码的人觉得整洁才算整洁".
回想起<代码整洁之道>里提到的,我们程序员其实绝大部分时间都是在读代码,而不是在写代码.根据统计,程序员几乎90%的时间都花在读代码上,真正写代码的时间只占到10%.这其中包括大量阅读自己之前写的代码.
代码的整洁与否关系到的是代码的可读性.可读性也是评判代码好不好的一个重要指标.
说到整洁代码,我们会想到哪些东西呢?
变量,函数的命名
接口的设计
恰到好处的注释
基本的内容实际上就只有这几点.当然我们会有一些设计原则,比如DRY(Don't repeat yourself),SRP(Single responsibility principle).
一般来说,好的代码要尽量遵循那些经典的设计原则(这里不是指具体的设计模式).
去除冗余代码,保持每个函数的功能单一(每个函数只做一件事).这些会显著提升代码的质量,提高代码的可读性,可扩展性.
对于老生常谈的命名问题,变量和函数的命名应该具有自描述性,读代码的人一看这个命名就能知道它是个什么东西,会起到什么样的作用.一般来说作用域小的变量可以使用缩写,而作用域大的变量尽量使用全称.
接口的设计要关注接口隔离原则,它实际上是SRP在接口这个层面的具体体现,接口和接口之间应该是相互隔离的,每个接口只做一件事.
具体而言,我们公司现在的规范里,每个flow和func只暴露一个对外方法,实际上是把接口隔离原则应用到了极致,这样可以让后续做代码复用时,不会使用到不需要的接口.
注释实际上是一个比较矛盾的东西.代码里不能完全没有注释,但注释也绝对不是越多越好.我们后续在改代码的时候经常会忘掉把注释一起改掉,这样就会造成代码和注释内容的不一致,从而给读代码的人造成不必要的疑惑.
个人而言,注释应该尽可能的少.大多数情况下,用恰当的函数和变量命名来实现自描述,读代码的人只需要看变量名和函数名就能理解它们的作用.只有在比较复杂的场景下,仅用命名无法解释代码逻辑的情况下,才写注释.
注释内容不能只写这段代码做了什么,更重要的是要说明为什么要这么做,它要解决的是什么样的问题.这样才能让读代码的人更好地理解这段代码.
