函数长度

1. 避免像 tmp 和 retval 这样泛泛的名字。不得不提到的一点是，tmp 实在是一个有

够烂的名字，将其变为 timeTemp 或者类似的会更直观。它只应该是名字中的一部分。

1. 用具体的名字代替抽象的名字。
2. 为名字赋予更多的信息。
3. 名字应该有多长。
4. 利用名字的格式来传递含义。

函数长度

函数是指一段在一起的、可以做某一件事儿的程序。

这就意味着从定义上来说，这段函数应该只做一件事——但是什么才是真正的一件事呢？实际上还是 TASKING，将一个复杂的过程一步步地分解成一个个的函数，每个

函数只做他的名称对应的事。对于一个任务来说，他有一个稳定的过程，在这个过程中的每一步都可以变成一个函数。

因此，长的代码意味着一件事——这个函数可能违反了单一职责原则，即这个类做了太多的事。通常来说，一个类，只有一个引起它变化的原因。当一个类有多个职责的

时候，这些代码就容易耦合到一起了。

对于函数长度的控制是为了有效控制分支深度。如果我们用一个函数来实现一个复杂的功能，那么不仅仅在我们下次阅读的时间会花费大量的时间。而且如果我们的代码

没有测试话，那么这些代码就会变得越来越难以理解。而在我们写这些函数的时候就没有测试，那么这个函数就会变得越来越难以测试，它们就会变成遗留代码。

其他

虽然只想介绍上面的简单的两点，但是顺便在这里也提一下重复代码 ~~。

重复代码在《重构》一书中首先提到的 Code Smell 就是重复代码（Duplicate Code）。

重复代码看上去并不会影响我们的阅读体验，但是实际上会发生这样的事——重复的代码阅读体验越不好。

DRY(Don’t Repeat Yourself) 原则是特别值得玩味的。当我们不断地偏执的去减少重复代码的时候，会导致复杂度越来越高。在适当的时候，由于业务发生变更，我们还

需要去拆解这些不重复的代码。