摘要

短胜于长，平优于深：过长的函数和嵌套过深的代码块的出现，经常是因为没能赋予一个函数以一个紧凑的职责所致（见第5条），这两种情况通常都能够通过更好的重构予以解决。

讨论

每个函数都应该是顾其名而能思其义，易于理解的工作单元（见第5条和第70条中的讨论）。如果与此相反，函数试图将多个这样的小概念单元合并到一个长的函数体中，那么它最终将不堪重负。

过长的函数和嵌套过深的代码块（比如if、for、while和try代码块）是使函数更难于理解和维护的密不可分的两大元凶（而且经常毫无必要）。

每级嵌套都会增加阅读代码时的脑力消耗，因为需要在脑子里维护一个“栈”（比如，进入条件语句、进入循环、进入try、进入条件语句……）。你是否有过这样的可怕经历：在别人编写的代码里众多的for、while和if语句中为一个右括号寻找匹配？应该做进一步的功能分解，从而避免使代码的阅读者一次记住太多的上下文。

请遵循这样的常识和常理：限制函数的长度和嵌套深度。以下所有的合理建议对这一点都有所裨益：

l     尽量紧凑：对一个函数只赋予一种职责（见第5条）。

l     不要自我重复：优先使用命名函数，而不要让相似的代码片断反复出现。

l     优先使用&&：在可以使用&&条件判断的地方要避免使用连续嵌套的if。

l     不要过分使用try：优先使用析构函数进行自动清除而避免使用try代码块（见第13条）。

l     优先使用标准算法：算法比循环嵌套要少，通常也更好（见第84条）。

l     不要根据类型标签（type tag）进行分支（switch）。优先使用多态函数（见第90条）。

例外情况

如果一个函数的功能无法合理地重构为多个独立的子任务（因为任何重构尝试都需要传递许多局部变量和上下文，使重构结果的可读性非但不好，反而更差），那么它的较长和嵌套较多就是合理的。但是如果有几个这样的函数都具有相似的参数，那么它们就有可能成为一个新类的成员。