摘录了一些内容,跟这些内容在书中出现的顺序不同,打散又整理了一下。除了斜体字部分,都是对原书的引用。

应该有的态度

  • 程序员遵从不了解混乱风险的经理的意愿,也是不专业的做法。

    做好自己的事,尊重自己的手艺,写干净的代码。

  • 糟糕的代码引发混乱!别人修改糟糕代码时,往往会越改越烂。

    碰到过“从跟上就烂”的项目代码,对这种项目的改造往往较为困难,成本很高,甚至不如推到重来。

  • 签入的代码,要比签出时整洁一点。

  • 代码应当讲述事实,不引人猜测。

  • 整洁的代码总是看起来像是某位特别在意它的人写的。

  • 聪明程序员和专业程序员之间的区别在于,专业程序员了解:明确是王道。

  • 言到意到。意到言到。

  • 如果同一段代码反复出现,就表示某种想法未在代码中得到良好的体现。

一些细节做法

  • (变量名的)名称长短与其作用域大小相对应。

  • 变量声明应尽可能靠近其使用位置。

  • 调用者应该尽可能放在被调用者上面。

  • 应该避免我们的代码过多地了解第三方代码中的特定信息。依靠你能控制的东西,好过依赖你控制不了的东西,免得日后受它控制。

    使用第三方库时,跟第三方库”划清界线“。一个可行的做法是把第三方库提供的接口再封装一层。业务代码只有自己的这层封装打交道,这样一来,如果要换用其他库,只改这个封装层,以此减少跟第三库的耦合以及依赖。

  • 看到注释掉的代码,就删掉它。

  • 否定式要比勘定式难明白一些。所以,尽可能将条件表示为肯定形式。

函数

  • 函数的第一规则是要短小。第二条规则是还要更短小。

  • 函数应该做一件事。做好这件事。只做这一件事。问题在于很难知道那件该做的事是什么。

  • 要确保函数只做一件事,函数中的语句都要在同一抽象层级上。

  • 在这个函数里做的事情,是同一个抽象层上的步骤,那么这个函数是只做了一件事。

  • 函数越短小、功能越集中,就越便于取个好名字。

  • 函数要么做什么事,要么回答什么事,但二者不可得兼。

错误处理

  • 最好把 trycatch 代码块的主体部分抽离出来,另外形成函数。

  • 函数应该只做一件事。错误处理就是一件事。因此,处理错误的函数不该做其他事。这意味着,如果关键字 try 在某个函数中存在,它就该是这个函数的第一个单词,而且在 catch/finally 代码块后面也不该有其他内容。

  • 错误处理很重要,但如果它搞乱了代码逻辑,就是错误的做法。

测试

  • 没有测试的代码不干净。

  • 不可测试的系统不可验证。不可验证的系统,绝不应部署。

  • 紧耦合的代码难以编写测试。

  • 编写测试引致更好的设计。

    写测试能够反过来逼着人写出更好的代码。

  • 测试消除了对清理代码就会破坏代码的恐惧。

  • 整洁的测试有什么要素?有三个要素:可读性,可读性和可读性。在单元测试中,可读性甚至比在生成代码中还重要。

  • 独立测试应该相互独立。某个测试不应为下一个测试设定条件。

  • 让测试具有表达力并短小精悍。