Gauss Zhou

Appearance

第一章 代码应当易于理解 ​

是什么让代码变得更好 ​

大多数程序员依靠直觉和灵感来决定如何编程。

我们都知道这样的代码：

cpp
for(Node* node = list->head; node != NULL; node = node->next) {
  Print(node->data);
}

比下面的代码好：

cpp
Node* node = list->head;
if (node == NULL) return;
while (node->next != NULL) {
  Print(node->data);
  node = node->next
}
if(node != NULL) {
  Print(node->data)
}

但很多时候这个选择会更加艰难。例如，这段代码：

cpp
return exponent >= 0 ? mantissa *  (1 << exponent ) : mantissa / (1 << - exponent);

它比下面这段要好些还是差些？

cpp
if (exponent >= 0) {
  return mantissa *  (1 << exponent );
} else {
  return mantissa / (1 << - exponent);
}

可读性基本原理 ​

在对很多这样的例子进行研究后，我们总结出，有一种对可读性的度量比其他任何的度量都要重要。因为它是如此重要，我们把它叫做“可读性基本定理”

关键思想

代码的写法应当使别人理解它所需的事件最小化

总是越小越好吗 ​

一般来说，你解决问题所用的代码越少就越好。很可能理解 2000 行代码写成的类所需的时间比 5000 行的类要短。

但少的代码并不总是更好！很多时候，像下面这样的一行表达式：

cpp
assert((!(bucket = FindBucket(key))) || !bucket->IsOccupied());

理解起来要比两行代码花更多时间：

cpp
bucket = FindBucket(key);
if (bucket != NULL) assert(!bucket->IsOccupied());

理解代码所需的时间是否与其他目标有冲突 ​

对于一个程序来说，更有效率、或者有好的架构、或者容易测试，这些目标会不会相互在有的时候与使代码容易理解这个目标冲突？ 我们发现这些其他目标根本就不会互相影响。就算是在需要高度优化代码的领域，还是有办法能让代码同时可读性更高。并且让你的代码容易理解往往会把它引向好的架构且容易测试。