老调重弹，一个象牙塔和产业背道而驰的事情。纯对事而言，现实中未必有；但是，必然会有类似的情况发生。所以，这个话题暂且算是一个警钟，仅此而已。 那么开始我们古老的命题：编写一个函数，求1+2+3+ …… +n。 标准答案是： C++代码 int getsum(int n)    {        int i;        int sum = 0;        for (i = 1; i <= n; ++i)            sum += i;        return sum;    }   但是，如果是在产品代码中，这个函数大多会这么写： C++代码 int getsum(int n)    {        return (1 + n) * n / 2;    }   一位名为LL的网友留言说：他当时刚学C的时候，老师出了道从1加到100的题，他就想过用高斯数列，但老师说他这不是编程，而是偷机取巧小聪明。 虽然高斯求和公式明显优于循环的解决方案，但是，对于课堂上讲授概念的示例来说，用循环来求解等差数列之和还是相当适合教学的例子，而高斯求和公式就显得不合时宜了。 很遗憾的是，我们的砖家和叫兽们在这个过程中并没有扮演一个光彩的角色。就像LL网友的老师一样，他们竟然对高斯求和公式采取了敌视甚至鄙视的态度。 我想，如果他们这么说，效果可能会更好一些—— “其实，对于这个问题来说，高斯数列才是更优的解决方案。但我在这里之所以使用循环，是为了让同学们能更容易地了解循环的概念和使用方法。” 我并不想把问题扩大化，但是的确有一个不容忽视的现状：如果你有机会的话，可以把这个命题作为求职笔试题用来考考应届毕业生，相信你一定会发现有一大半学生的思维方式被禁锢在了象牙塔内。

今天的话题是从一个比较苛刻的角度出发的——命名，如果你觉得我是在杞人忧天的话，请无视并跳过。 C++代码 #include <stdio.h>       #define sqr(x) x * x       int main(void)    {        int a = 10, k = 2, m = 1;        a /= sqr(k + m) / sqr(k + m);        printf("a = %d ", a);        return 0;    }   代码很简单，题目的要求是写出程序运行的结果，考点是学生对于宏函数的理解。这个题的正确解法是，使用“x * x”来忠实替换所有的sqr宏括号中的文本。也就是说，最关键的一句将会被解释成： C++代码 a /= k + m * k + m / k + m * k + m;   而不是 C++代码 a /= (k + m) * (k + m) / (k + m) * (k + m);   因此，这道题的正确答案应该是1，而不是10。如是一来，学生对于宏的机制的理解便加深了。 到现在为止，似乎所有的一切都没有问题。但其实不然，这里面存在着一个不容忽视的命名问题： 在没有看到sqr的具体定义之前，你认为它是做什么的？ square，平方。——我认为，这个解释是约定俗成的。但事实上，这个宏并不是求平方用的。我们那些伟大的、富有创造力的砖家和叫兽们把这个宏用在了一个病态的考察环境中。 或许我应该把这个理解为试卷上一个合理的心理陷阱，且用来考察学生对知识的掌握是否绝对够硬？ 如果你企图让我承认这一点，那么请在任何的产品代码中找出类似的例子，先。或者说，作为程序员的你是否有胆量在协作的代码中写下这样的宏给别的程序员调用，以考察他们对宏函数概念的理解？ 那么，来说我的观点。按照约定俗成，我建议这个宏在试卷上应该定义成下面的样子： C++代码 #define foo(x) x * x   不知道foo含义的朋友们可以google一下。 末了，再聊聊有关命名的另一个问题。我们教材上的示例代码往往一口气定义很多一个字母的变量：a如何如何、b如何如何、c如何如何最后d如何如何……简而言之，这样的写法实在是望文难以生义，在弄懂代码的意思之前，先被变量的名字搞晕了。 我太苛刻了吗？先不要觉得我苛刻，且看： 1号传球给2号，2号传球给3号，3号传球给4号，4号射门，球进了。 如果你看球的时候喜欢听这样的解说词，那我承认我很苛刻就是了。

关于递归，《代码大全》（第2版）的P397～398如是写道： 在计算机科学教科书中存在着这样的缺陷，那就是用愚蠢的例子来讲解递归。典型的例子就是计算阶乘或者斐波纳契数列。递归是一种强有力的工具，但是把它用在这两者中的任何一种都是愚蠢之极的。如果为我工作的程序员用递归去计算阶乘，那么我宁愿换人。 接下来，对于这个问题的理由，作者解释道： 除了速度缓慢，并且无法预测运行期间的内存使用状况以外，用递归写出的子程序要比用循环写出的子程序更难理解。 最后，作者为之总结了三点经验： 首先，计算机科学教程中给出的递归示例没有给这个世界带来任何的好处。 其次，也是更为重要的，递归是一种非常强大的工具，其功能之强大要远远超出使用它们来稀里糊涂地计算阶乘或者斐波纳契数列。 再次，也是最重要的，在用递归之前你应该考虑它的替换方案。 之所以援引《代码大全》原书这么多的内容，是由于国内的确有很多的学究课本使用了阶乘或斐波纳契数列来讲解递归。也许砖家和叫兽们找不到更合适的示例，又也许是他们的程序永远运行在超高速CPU和无限内存的机器上——这一切，我是无从得知的。我唯一了解的情况是：我们现实中所使用的机器并不能给我们提供一个理论上完美的运行环境——亦即是说，在某些严苛的条件下，你用来计算阶乘或斐波纳契数列的代码将有可能收到一个系统崩溃。 掌掴学究欢迎提供各类素材，请致信titilima@163.com。

好了，就从最为臭名昭著的“(++i) + (++i) + (++i)”开始吧。 C++代码 int i = 4;    int a = (++i) + (++i) + (++i);   题目要求是求a的值，多见于各种等级考试、期末考试的选择题。 显然，这道题的考点是前缀自增运算符。与之相似的还有后缀自增（减）或前后缀增减混合的情况。 一墙之隔，围城内外。在象牙塔外的世界，这个题目是最早遭到诟病者之一。因为，出题者所默认的程序运行环境是Turbo C，所以标准答案自然也就是TC的运行结果（有TC的朋友们不妨试一试，看看TC的结果是不是你那卷子上的标准答案）。而事实上，对于这个题目的结果，a的值是无法预期的——C/C++标准规定，三个++i的子表达式是没有求值顺序点的，同时它们又是有副作用的，因此语言本身并不能保证副作用的顺序。 眼见为实，让我们来看看三款不同编译器产生的代码吧。我为每个必要的细节加了注释，以便理解。 汇编代码 ; Visual C++ 6.0 sp6：    mov [ebp+i], 4   ; i = 4    mov eax, [ebp+i]    add eax, 1       ; ++i, i == 5    mov [ebp+i], eax    mov ecx, [ebp+i]    add ecx, 1       ; ++i, i == 6    mov [ebp+i], ecx    mov edx, [ebp+i]    add edx, [ebp+i] ; 6 + 6 == 12    mov eax, [ebp+i]    add eax, 1       ; ++i, i == 7    mov [ebp+i], eax    add edx, [ebp+i] ; 12 + 7 == 19    mov [ebp+a], edx ; a = 19       ; Visual Studio 2005：    mov [ebp+i], 4   ; i = 4    mov eax, [ebp+i]    add eax, 1       ; ++i, i == 5    mov [ebp+i], eax …

两年之前，年少轻狂的我曾为中国象牙塔中的计算机教育做出了两个预言： 十年内，中国本科的计算机教育要发生一场大变革。 二十年内，中国高校的就业大门将会重新对社会上的高龄程序员敞开。 对此，我在那篇名为《预言》的blog中做出了如是的解释： > 可以说，当前中国高校的计算机教育已经完全和IT产业背道而驰了。这 > 个自闭排外的象牙塔仍然使用腐朽的学究思想来教育计算机系的学生 > 们，最后所导致的一个结果就是大多数本科生毕业后都无法找到理想的 > 工作。原因是显而易见的：IT产业需要的是技术牛人，而不是腐朽学 > 究。所以，当这种就业矛盾发展到不可调和的时候，教育的变革就会以 > 迅雷不及掩耳盗铃之势骤然爆发。在变革爆发后，计算机教育与IT产业 > 的接轨将会成为最主要的一环。教育需要真正能面向产业的技术，但久 > 居象牙塔的讲师教授硕士博士们是无法胜任的，所以高校必定会重新从 > 业界补充新鲜血液，善于表达授课的高龄程序员们就可以功成身退衣锦 > 还校了。 逝者如斯夫，近两年过去了，情况貌似没有丝毫的好转。我渐渐明白：任何的一个变革都应该首先从自己做起。于是，我在我的个人网站上专门开设了一个分类，同时在人气颇高的新浪blog上开通了一个账户，用于对出现在教材、试卷上的各种具有误导性的劣质代码予以分析并纠正其错误。对于这个话题的讨论，我名之为“掌掴学究”——误人子弟的代码，实在是欠抽大耳刮子。另，本专栏纯属炒作，如有冒犯，毋必恕罪。 掌掴学究专栏欢迎提供各类素材，请致信titilima@163.com。 ———-传说中的分隔线———- 掌掴学究@sina：http://blog.sina.com.cn/titilima