清理代码也许只是改好一个变量名,拆分一个有点过长的函数,消除一点点重复代码,清理一个嵌套 if 语句。当梳理代码时,坚守此军规:每次 review 代码,让代码比你发现它时更整洁。
一、谨慎命名
给函数和变量取个好名字是优秀程序员的基本功,取名的基本要求是 名副其实,见文知意。如果名称需要注释来补充,那就不算是个好名字。
1 var d // 日期
修改为:
1 var date
取名的第二个要求是 避免误导。比如数据本身不是一个 list,那就别用 list 来命名,因为 list 一词对程序员有特殊的含义。
修改为:
取名的第三个要求是 去掉冗余。Variable一词永远不应当出现在变量名中,Table一词永远不应当出现在表名中。nameString 会比 name 好吗?ProductInfo 、 ProductData 和 Product 有什么区别?更糟糕的是,如果代码中同时存在 Article 和 ArticleInfo 类,程序员怎么知道该调用哪个类呢?多个意义含混的冗余词汇只会让阅读者困惑,要区分名称,就要以读者能鉴别不同之处的方式来区分。
例如:开始你用了 address 变量表示用户居住地,如上海、北京。后来又要求更详细地描述用户的居住地。如上海黄浦区、浦东区,北京海淀区、朝阳区。用什么来命名这个详细地址呢?detailAdress?smallAddress?还是 anotherAddress?这些统统都不是好的做法,牢记上述法则:以读者能鉴别不同之处的方式来区分,这时比较好的做法是修改之前的 address 变量名字为 city,再将区域的地址命名为 district。
取名的第四个要求是:严谨,不要俏皮。笔者曾经接手一位外国同事写的代码,在一个类中,这位外国同事使用了 wearClothes、wearPants 命名函数,之后又出现一个 startParty 函数。仔细理解后,笔者才发现,这是代表软件系统的第一步准备、第二步准备,然后正式启动这三个流程。或许这位同事写这个类时心情不错,将其比喻成了一个 party 的流程,但对于读者来说,梳理这三个函数的意思着实要费一番心思。事实上,此时我们最好将其命名为 firstStepOfPreparation、secondStepOfPreparation、systemBoot,宁可明确,毋为好玩。
二、函数和类
函数和类应该坚持 单一权责原则。保持高内聚,低耦合。隔离会让系统每个元素的理解变得容易。
单一权责原则:在面向对象编程领域中,单一权责原则(Single responsibility principle)规定每个类都应该有一个单一的功能,并且该功能应该由这个类完全封装起来。一个类或者模块应该有且只有一个改变的原因。
过长的函数会造成不易理解,如果某天这个函数需要修改的话,一个长长的函数会大大增加理解成本。并且,小函数也能更好地复用。
如果一个函数做了多件事,一个明显的标志是无法为它起一个精准的名字。你会觉得需要函数名需要使用 and 连接,比如 calculateAndPrintPrice,这时候最佳做法是将其拆分为 calculatePrice 和 printPrice 两个小函数。
函数的第二个规范是 尽量不要在参数中传递状态值,状态值是函数做了多件事的明显标志。例如:
修改为:
函数的第三个规范是 同一个函数中的代码应该属于同一层级。良好的软件设计要求分离位于不同层级的概念,较低层级概念和较高层级概念不应混杂在一起。
修改为:
三、坏注释与好注释
注释并不是越多越好,有的注释纯属无意义的废话,例如:
这些注释看起来就像是喃喃自语,或许读者阅读这些注释的时间比读代码还要长。好的注释只应该用在必要时,用于警告其他程序员会出现某种后果的注释是有用的,例如:
写注释的常见动机之一是原有代码混乱。当我们阅读代码时,发现已有的代码令人困扰、乱七八糟。这时我们也许会告诉自己:“等我阅读清楚后,给它写点注释!”别那样做!最好的做法是把代码整理干净。
修改为:
四、良好的格式
在我们阅读报纸时,在顶部,你期望有个头条,告诉你故事的主题。然后第一段是整个故事的大纲,给出粗线条概述,但隐藏了故事细节。接着读下去,细节渐次增加,直至你了解所有的细节。
代码的格式也要像新闻文章一样,最顶部给出高层次概念,向下渐次展开细节。函数应该紧跟调用处,保证垂直方向上的靠近。如果格式混乱,读者在阅读时总会滑上滑下,导致思维跳跃,增加不必要的理解难度。
影响格式的第二个要素是 缩进与间隔,现代化的 IDE 都有格式化代码快捷键,你也可以在设置中搜索"Reformat Code",自定义格式化代码快捷键。随时格式化,并去掉多余的空行,让我们的代码保持清爽、整洁。
五、数据结构
在有的源代码中,作者采用长长的链式调用,甚至会鼓吹自己只写了一行代码便实现了此功能。事实上,绝不应该为了节省变量,写过长的链式调用,否则容易造成"火车失事"。正确的做法是遵守“得墨忒定律”:适当拆解链式调用,只和朋友谈话,不和朋友的朋友谈话,使得代码阅读和调试都更方便。
得墨忒定律(The Law of Demeter):模块不应该了解它所操作对象的内部情形。
修改为:
六、错误处理
在处理程序异常时,我们常常会用到 try / catch 代码块,而 try / catch 代码块丑陋不堪,他们搞乱了代码结构,把错误处理与正常流程混为一谈。最好的做法是 把 try 和 catch 代码块的主体部分抽离出来,另外形成函数。错误处理就是一件事。
现代化的语言都有异常机制,异常情况如果不及时加以处理,可能会导致程序崩溃。所以有的程序员对于程序的异常情况会选择返回 0 或者 -1 等错误码,以保持程序不崩溃。
别这样做,正确的做法是将错误码替换为抛出异常,只有这样才能保证出现错误时立马就可以发现,而不是让程序在错误的状态下继续执行,将来造成更加迷惑的错误。
要讨论错误处理,就一定要提及那些容易引发错误的做法。第一项就是返回 null 值。我不想去计算曾经见过多少几乎每行代码都在检查 null 值的应用程序。返回 null 值基本上就是在给自己增加工作量,也是在给调用者添乱。只要有一处没有检查 null 值,应用程序就会失控。返回 null 不如抛出 NullPointerException ,或是替换为一个 空对象。让调用者不再需要检查 null,代码也就更整洁了。