Clean Code读书笔记

前一段时间看完了 Clean Code 这本书，今天就把我记录在印象笔记中的一些笔记搬到这里来吧（可能比较随意，以后再来更新吧）

（1）

类应该短小

只要遵循以下规则，设计就能变得“简单”：

运行所有测试

不可重复

表达了程序员的意图

尽可能减少类和方法的数量

以上规则按期重要程度排列

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

130 TDD 三定律

TDD 要求我们在编写生产代码前写编写单元测试，

测试代码和生产代码一样重要，它需要被思考，被设计和被照料，应该像生产代码一般保持整洁

整洁的测试的要素：可读性

明确，简洁，还有足够的表达力

134

测试显然呈现了构造-操作-检验模式

第一个环节构造测试数据，

第二个环节操作测试数据，

第三个部分检验操作是否得到期望的结果

135

整洁的测试遵循以下 5 条规则：

Fast

Independent

Repeatable

Self-Validating

Timely

double dataminant = daterminant(a, b, c)

     return (-b + Math.sqrt(determinant)) / (2*a)

     returnb*b -2*a*c

乘法因子之间没加空格，因为他们具有较高优先级，加减法运算项之间用空格隔开，因为假发和减法优先级较低

（2）

与其花时间编写解释你搞出的糟糕的代码的注释，不如花时间清洁那堆糟糕的代码

 

用代码来阐述：

有时，代码本身不足以解释其行为。不幸的是，许多程序员据此以为代码很少——如果有的话——能做好解释工作。这种观点纯属错误。你愿意看到这个：

// Check to see if the employee is eligible for full benefits

if ((employee.flags & HOURLY_FLAG) &&

     (emplyee.age > 65))

还是这个？

if (employee.isEligibleForFullBenegits())

警示：

下面的注释解释了为什么要关闭某个特定的测试用例

// Don't run unless you

// have some time to kill

第一规则：短小

只做一件事：

（1）判断是否为测试页面

（2）如果是，则容纳进设置和分拆步骤

（3）渲染成 HTML

使用描述性的名称：

沃德原则：如果每个例程都让你感到深合己意，那就是整洁代码

别害怕长名称，长而具有描述性的名称，要比短而令人费解的名称好， 长而具有描述性的名称，要比描述性的长注释好

函数参数：

最理想的参数数量是0， 其次是一，二，三

分隔指令与询问：

函数要么做什么事，要么回答什么事，但两者不可兼得。函数应该修改某对象的状态或是返回该对象的有关信息，两样都敢常会导致混乱

例子：

该函数设置某个制定属性，如果成功就返回 true，如果不存在那个属性则返回 false。这样就导致了一下语句：

if (set("username", "unclebob"))

真正的解决方案是把指令与询问分隔开来，防止混淆的发生：

     if (attributeExists ("username")) {

         setAttribute("username", "unclebob")

     }

抽离 Try / Catch 代码块

Try / catch 代码块丑陋不堪。他们搞乱了代码结构，把错误处理与正常流程混为一谈。最好把try 和 catch 代码块的主体部分抽离出来，另外形成函数

（3）

有意义的命名：

intelapsedTimeInDays

intdaysSinceCreation

intdaysSinceModification

intfileAgeInDays

做有意义的区分：

public static void copyChars(char source[], char destination[]) {

     for (int i = 0; i < a1.length; i++) {

         source[i] =destination[i] 

     }

}

使用可搜索的名称：

5 或者是const int WORK_DAYS_PER_WEEK = 5

方法名：

方法名应该是动词或动词短语，如 postPayment, deletePage, save

string name = employee.getName();

customer.setName("mike")

每个概念对应一个词：

例如，使用fetch, retrieve 和 get 来给在多个类中的同种方法命名。你怎么能记得住哪个类中是哪个方法呢？

同样，在同一堆代码中有 controller, manager, driver，就会令人困惑

不要添加没用的语境：

GSDAccountAddress 这名字听起来没问题吗？在这 17 个字母里面，有 10 个字幕纯属多余和当前语境毫无关联

隐藏结构：

BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName)

对象暴露行为，隐藏数据。便于添加新对象类型而不需修改既有行为，同时也难以在即有对象中添加新行为。数据结构暴露数据，没有明显的行为。便于向既有数据结构添加新行为，同时也难以向既有函数添加新数据结构

在任何形容中，我们有时会希望能够灵活地添加新数据类型，所以更喜欢在这部分使用对象。另外一些时候，我们希望能灵活地添加新行为，这时我们更喜欢使用数据类型和过程。优秀的软件开发者不带成见地了解这种情形，并依据手边工作的性质选择其中一段手段

测试代码和生产代码一样重要，它需要被思考，被设计和被照料，它该想生产代码一般保持整洁