函数最初的用处
大家刚学编程的时候，一定还记得为什么要用函数。那就是把重复的代码归纳到一个函数中多次利用。这点毋庸置疑，大家也用的很熟了，但是除了这个还有什么改进空间吗？答案肯定是有的！
PS.本文不讨论面向对象、不讨论设计模式，只是把视线聚焦在 Class 内部的函数上。
出现什么问题了？
大家都知道当一个函数很长的时候，就会造成阅读困难，那以前我们都是怎么解决的呢？
- 写注释：这个大家都知道怎么用，也是一种有效的方法。
- 用 #region 代码块：这个也是一个行之有效的方法。
还有什么别的方法吗？其实还有一个方法就是文章的标题：使用短函数。
在讨论短函数有点之前，我想先用一点篇幅来讲述一下什么时候改写注释。
路人甲：纳尼？不是说任何时候都要写注释吗？
什么时候该写注释
注释主要就有两个用途：
- 在 Class 和 别的函数、字段、属性前打三个 / ，就会自动生成供 VS 使用的智能提示内容。
- 解释代码意图。
第一点大家都会用，而且就这么用，没有什么替代的办法。
但是关于第二点，注释未必是最好的解决办法。
因为如果一段代码让人看不懂，要么就是“英文看不懂”，要么就是“逻辑复杂”。
注释是为了弥补它们带来的缺点，但是为什么不从根本解决呢？
“英文看不懂”：每个程序员都应该有一定的英文基础吧？另外注意命名规范，就可以解决了。
“逻辑复杂”：如果一段程序逻辑复杂，让人看不懂，你觉得你应该费力地去给别人解释呢？还是自己好好整理整理，把代码梳理一下呢？
那怎么梳理你的代码呢？短函数？
短函数的优点——有助于梳理代码
我想废话不多说了，都是程序员，大家一看代码就明白了。
这里贴上另外一篇文章：《代码才是最好的注释》
文章的题目是代码才是最好的注释，其实写的就是短函数的优点。
已经有了文章，我就不重复工作了。
顺便提一下 region ，其实 region 在 VS 下的收缩功能可以达到差不多的效果，你可以选用这个，但是不是很推荐。
下面，我还要和大家探讨一下另一个优点。
短函数的优点——在 .Net 下可优化性能
关于这点，我是在《More Effective C#》中看到的，觉得非常好，所以推荐给大家。
把一个大函数拆分成很多小函数可以优化性能？这点看上去很可笑。是的，其实这点性能的提升微不足道，但是如果可以，为什么不做呢？更何况这样做还有上面说的另一个优点。
为什么长函数分割成短函数的时候可以优化 .Net 下的性能呢？
你首先要明白：
.Net 下的语言编译的时候只是编译成了中间语言。运行的时候，它会再一次编译成机器码。
这个中间语言编译成机器码是以一个函数为基本代为的。也就是说，每次调用函数的时候，这个函数才会被编译。
那长函数分割成了短函数有优势吗？代码量不还是一样的？纯粹的分割反而会产生更多的代码呢！
的确如此，所以说，这里还有另一个条件：当这个长函数中有很多分支的时候。
public void Func1()
{
if(xxxx)
{
//代码段1，几百行
}
else
{
//代码段2，几百行
}
}
上面这段代码，有两大段代码，每次调用这个函数其实只会执行一部分。
所以，如果把这两块代码段提取出来，编译的过程中就会少编译一半的代码。
现在明白在什么时候把长函数分割成短函数能优化性能了吧。
虽然这点性能提升并不明显，但是，如果你一个函数中，有一个很大的分支。
你在看代码的过程中，一定会看花眼，滚屏的过程中，都不知道自己现在身处在哪个部分。
随意就算不考虑性能，也推荐把这样的代码分割成短函数！
总结
上文说了短函数的优点，说了下注释的缺陷，还有一个没怎么提到的 region …
我在写代码的时候一般遵循一下原则：
- 函数内部一般不写注释，如果“逻辑复杂”，我会优化逻辑并分割成短函数。
- 在一些算法中，包含很奇特的公式，这个一定要写注释了，没办法分割和优化。
- 写完函数后查看是否有大段的分支，有的话再分割成短函数。
最后，希望本文能对大家有用！
本作品由 Dozer 创作，采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可。