《编写可读代码的艺术》——重新组织代码

把控制流变得易读

把条件、循环以及其他对控制流的改变做得越“自然”越好。运用一种方式使读者不用停下来重读你的代码。

?:条件表达式（又名“三目运算符”）

相对于追求最小化代码行数，一个更好的度量方法是最小化人们理解它所需的时间。

避免do/while循环

我的经验是，do语句是错误和困惑的来源……我倾向于把条件放在“前面我能看到的地方”。其结果是，我倾向于避免使用do语句。

从函数中提前返回

通常来讲提早返回可以减少嵌套并让代码整洁。“保护语句”（在函数顶部处理简单的情况时）尤其有用。

最小化嵌套

当你对代码做改动时，从全新的角度审视它，把它作为一个整体来看待。

嵌套的代码块需要更加集中精力去理解。每层新的嵌套都需要读者把更多的上下文“压入栈”。应该把它们改写成更加“线性”的代码来避免深嵌套。

通过提早返回来减少嵌套

减少循环内的嵌套

在循环中，与提早返回类似的技术是continue：

与if(...)return;在函数中所扮演的保护语句一样，这些if(...) continue;语句是循环中的保护语句。

你能理解执行的流程吗

然而在实践中，编程语言和库的结构让代码在“幕后”运行，或者让流程难以理解。

下面是一些例子：

编程结构	高层次程序流程是如何变得不清晰的
线程	不清楚什么时间执行什么代码
信号量/中断处理程序	有些代码随时都有可能执行
异常	可能会从多个函数调用中向上冒泡一样地执行
函数指针和匿名函数	很难知道到底会执行什么代码，因为在编译时还没有决定
虚方法	object.virtualMethod()可能会调用一个未知子类的代码

拆分超长的表达式

把你的超长表达式拆分成更容易理解的小块。

用做解释的变量

拆分表达式最简单的方法就是引入一个额外的变量，让它来表示一个小一点的子表达式。这个额外的变量有时叫做“解释变量”，因为它可以帮助解释子表达式的含义。

总结变量

即使一个表达式不需要解释（因为你可以看出它的含义），把它装入一个新变量中仍然有用。我们把它叫做总结变量，它的目的只是用一个短很多的名字来代替一大块代码，这个名字会更容易管理和思考。

使用德摩根定理

如果你学过“电路”或者“逻辑”课，你应该还记得德摩根定理。对于一个布尔表达式，有两种等价的写法：

• not (a or b or c) <=> (not a) and (not b) and (not c)
• not (a and b and c) <=> (not a) or (not b) or (not c)

如果你记不住这两条定理，一个简单的小结是“分别取反，转换与/或”（反向操作是“提出取反因子”）。

有时，你可以使用这些法则来让布尔表达式更具可读性。例如，如果你的代码是这样的：

if (!(file_exists && !is_protected)) Error("Sorry, could not read file.");

那么可以把它改写成：

if (!file_exists || is_protected) Error("Sorry, could not read file.");

不要滥用短路逻辑

变量与可读性

变量的草率运用如何让程序更难理解。确切地说，我们会讨论三个问题：

• 变量越多，就越难全部跟踪它们的动向。
• 变量的作用域越大，就需要跟踪它的动向越久。
• 变量改变得越频繁，就越难以跟踪它的当前值。

减少变量

• 没有价值的临时变量
• 减少中间结果
• 减少控制流变量

缩小变量的作用域

让你的变量对尽量少的代码行可见。

很多编程语言提供了多重作用域/访问级别，包括模块、类、函数以及语句块作用域。通常越严格的访问控制越好，因为这意味着该变量对更少的代码行“可见”。

从某种意义上来讲，类的成员变量就像是在该类的内部世界中的“小型全局变量”。尤其对大的类来讲，很难跟踪所有的成员变量以及哪个方法修改了哪个变量。这样的小型全局变量越少越好。

另一个对类成员访问进行约束的方法是“尽量使方法变成静态的”。静态方法是让读者知道“这几行代码与那些变量无关”的好办法。

或者还有一种方式是“把大的类拆分成小一些的类”。这种方法只有在这些小一些的类事实上相互独立时才能发挥作用。如果你只是创建两个类来互相访问对方的成员，那你什么目的也没达到。