【程序员的闲话家常 之二】函数可以写多长？
项目组做Code review， 几位兄弟就函数长短的问题进行论战，难以定论。
200行的函数到底算不算太长？是不是“完全没有可读性”？ 一个函数多长算“太长”呢？
这其实是一个古老的话题了。印象当中最早看到这个话题是林锐的《高质量C++编程》，似乎是说一个函数最好在50行以内。50行，恩，还行，我觉得不算太长。可是200行以内的函数我觉得也还都OK。300行呢？也许，似乎，大概...也不算长吧。
网上随便搜搜。
有人觉得函数不应该超过5行。这家伙肯定写的都是从1加到100的函数。
有人觉得函数不应该超过20行。呃——检查一下函数输入参数，留两个空行，如果每个大括号还要单独占一行，大概也没剩下几行干活的代码了。
有人觉得函数不应该超过100行。可是100行跟200行有什么本质区别么？
有人觉得函数几百行也是可以的，只要流程不是写得很复杂。这个几百行其实比较模糊了。
有人觉得函数不应该超过1K。基本上一个程序员很少写到这么长的函数，不说也罢。
函数行数应该有个上限的。为什么？因为一个函数太长了，看起来就不方便了。这一点，大家都认同吧。想象一下一个函数写了1W行，那是多么恐怖的事情（晚上吃饭时聊天，居然还真有这样的案例-_-! ORZ呀）。
按照功能把联系较为紧密、有复用性的部分分离为函数。大多数程序员认同这样的设计。
问题在于每个人的容忍程度是不同的。
比如我，不能容忍太多的函数，而宁愿将一个功能中没有复用性的代码写在同一个函数里。况且将一个功能分为多个函数更影响我阅读，因为我用VIM。而且函数多了又要多写不少检查输入参数、返回值的代码，挺恶心的（你要是不喜欢检查函数参数，那么又会犯了一些其他的代码风格忌讳了，甚至可能导致一次好好的笔试名落孙山哦）。
而另外一些程序员对函数长度更为在意，为了限制长度，他们会从一个功能分出若干步骤，写为不同函数，用SourceInsight这样的高档dd阅读这种代码确实也挺方便。
对函数长度比较执着的人，就会对超过自己习惯长度的函数产生厌弃感。这可能是认为长函数可读性差的根源。
其实，类似地，一个类成员函数分得太多也会令使用者和研究者头疼。即便是C++标准委员会的主席Herb Sutter也觉得std::string的成员函数太多是个糟糕的设计。 毕竟从使用者的角度看，大家更希望接口少一点、清晰一点，这样可以降低学习成本，也就减少犯错的机会。
那么怎么会形成“太多”OR“太长”的结论呢？不同的人有不同的结论。侧面举个例子。我写一个概要设计文档，送给一个老大A看，他说：“写得太简单了，我看不懂。”丰富一通以后，老大A说：“不错。”再送给老大B看，老大B翻一翻说：“你一个概要设计怎么写这么罗嗦，像个详细设计一样。”晕倒。。。吐血。。。
以前我们说编程是门艺术，那么现在我要说评价程序是门哲学。
有兴趣的人可以翻翻mysql、apache、linux内核或者其他一些开源项目的源代码，里面的风格五花八门，可以发现很多乐趣，甚至不乏上千行的函数，例如glibc的vfprintf函数1500+行。
从这个话题还可以衍生出很多类似话题：比如一个类最多有多长？一个类最多多少个成员函数？一个程序最多多少个文件？一个项目该用较少的程序做完所有事情还是把功能分解开来做成若干个程序？
无奈，这种涉及程序风格的话题永远讨论不出结论，各个项目投票决定一个项目组内大多数人能接受的标准饼严格执行即可（我也碰到过因为个别顽固派导致多数派投票结果流产的案例）。需要注意的是，这种标准通常应该是客观的、最好可量化的。如果你为了让标准容易获得通过而制定一些需要主观评判的标准，那么这一切纯粹只会浪费时间。
至于项目组之外，还真没一个统一的标准来限定函数的长度。所以我一般不用函数长短来评判函数的可读性。
相关链接：
