这两天，我在读一本书，书名叫《高质量C++/C编程指南》（作者：林锐 博士）。
　　开始读前，我以为可以从书中学到许多编程技巧。读了才知道，这本书讲的完全是另外一回事——编程风格。
　　程序员们（偷猫从来没认为自己是程序员）每天做的事，就是写代码完成自己需要的功能；负责任的程序员，还要升级自己的代码以减少可能的BUG和增加对新要求的适应；稍微优秀一点的程序员，还会考虑怎样让代码更加高效。——但是，程序员的通病是不注意代码的风格。
　　我与计算机程序打交道11年了，自以为自己一直是按照良好的风格去写的，但我每次看这方面的著作时，总是发现自己要走的路还很远——可喜的是，我比较愿意接收一些优秀的忠告。——的确如此，我在写程序时非常注意这一方面，倒不是为了煊耀，而是这样写确实给我自己带来了很多方便。我在帮别人检查代码时，还经常指出他在风格上的不足，建议他改掉（人家听不听那倒是另外一回事）。
　　回想想我自己的风格养成，是经历了很长的时间的，说来要归功于“吃一堑，长一智”。1997年，为了更好地锻VB，我放开书本自己动手编游戏。小时候玩过塑料的《华容道》，这个游戏只有规则、没有人工智能。当时费了九牛二虎之力，终于把游戏做出来了。接下来又做了个略带人工智能的《黑白棋》。半年后，我又回头看自己做的《华容道》，这才知道原来自己写的程序也会看不明白。从那时起，我才开始注意自己的风格。
　　人总在进步，但是仅按自己的逻辑进步，有时可能是退步。在程序的风格上这点很常见。人不是圣人，不可能知道自己离“修成正果”还有多远，所以，人最容易犯的错误就是把自己会的一点点东西当成人类知识的巅峰。通俗地说就是自以为是。
　　2002年3月份，就在《西祠胡同》，有一个网友发贴将自己写的C程序源码公布出来，说“可悲呀可悲！我的开发终究没有按期完成，大量的错误亟待解决，但是我已经没有时间……”，所有看过的人一起把他的程序当成了一个很好的反面教材，因为在那段长达17K的程序中，有效的注释只有零星几个（后来我认真数了一下，是14个），绝大多数地方没有缩进，倒是有很多地方有胡乱缩进。发贴人把自己的“可悲”强加给了“没有时间”，却没有意识到真正的可悲在哪里。——这本身就是一个可悲。
　　我有好多从事编程的朋友，他们几乎无一例外地说：“那种风格我也会的，只是不高兴。”说得是如此地理直气壮。有句俗话叫“千金难买我愿意”，自己愿意看自己写的东西，你管得着么？是的，我没有足够的理由来说服同道中人，但是我有权利在我自己看的东西上好好做点文章。
　　如果再把程序执行效率牵扯进来一起讨论，更多的人会卷入这场无休止的争论。许多程序员认为自己写的程序是最好的，因为执行速度快、因为节约内存。典型的是“if(p)”和“if(p != NULL)”之争。至于由此带来的对开发效率的浪费，因为找不到一个公认的权衡点，所以这场争论注定要毫无结果。
　　《高质量C++/C编程指南》从头到尾主要围绕着程序的可读性来提出要求，对于喜欢自以为是的程序员（包括我本人，虽然从不认为自己够得上“程序员”，但同样自以为是）来说应该是个很好的教育。可喜的是，已经有越来越多的人接受了该书的忠告，这点从网上的讨论可以看出来。
　　在我的这篇文章结束之前，引用几段该书前言中的内容，至所以要引用，因为我看到这些内容时吓了一跳，还因为我想多看看它们：
　　“我到上海贝尔工作一年来，陆续面试或测试过近百名‘新’‘老’程序员的编程技能，质量合格率大约是10％。很少有人能够写出完全符合质量要求的if语句，很多程序员对指针、内存管理一知半解，……。”
　　“领导们不敢相信这是真的。我做过现场试验：有一次部门新进14名硕士生，在开欢迎会之前对他们进行‘C++/C编程技能’摸底考试。我问大家试题难不难？所有的人都回答不难。结果没有一个人及格，有半数人得零分。竞争对手公司的朋友们也做过试验，同样一败涂地。”
　　“要知道华为、上海贝尔、中兴等公司的员工素质在国内IT企业中是比较前列的，倘若他们的编程质量都如此差的话，我们怎么敢期望中小公司拿出高质量的软件呢？连程序都编不好，还谈什么振兴民族软件产业，岂不胡扯。”