2008年到2009年，金融危机的影响在软件行业发酵，微软宣布的5000人裁员计划再现了西雅图不眠夜，而国内软件公司也“裁员滚滚”。看来，软件业的重组和洗牌是在所难免的，然而大批从计算机专业毕业的应届生，还有众多的计他们常常在思考如下问题：应聘者该怎样应对招聘公司的笔试？职场新手，又怎样迅速成为团队中一员？如何开发出维护性、扩展性、可读性都很优秀的代码？如果你是他们中的一员，笔者希望以自己的经历帮你寻找答案，或许这会帮助你跨出职业的第一步。
我去年七月参加工作，成为一名C++程序员，面对的是微软十多年累积的代码。无论是应聘时的笔试经历，还是开发团队协作的项目经验都告诉我，越来越多的软件公司将合格程序员的评判标准从基础知识、编程思想、代码量，扩大到了编程风格。尤其对刚毕业的新手来说，单凭一本林锐的《高质量C++编程指南》，打遍职场都不怕的时代已经一去不返了。而这本书――《The Elements of C++ Style》(《C++编程风格》)也许会给迷惘的你一点帮助。
正如引言中所述，“编程语言的语法告诉你可以写什么样的代码――条件是机器能够阅读并理解。而风格告诉你应该如何写代码――条件是人类可以阅读并理解”。这本书的目的是萃取前辈们几十年编程经验的精华，归纳总结为易学习、有启发、较成体系的实践规则。主题部分分为七章，一般原则、格式约定、命名约定、文档约定、编程原则、编程约定和打包约定。它沿袭了备受推崇的经典风格指南Strunk、White的The Elements of Style和Kernighan、Plauger的The Elements of Programming Style的组织方法，全部规则以名单的形式给出，每个规则包含一段文字说明和例子。这些规则在内容上又可以分为逐层递进的三个部分：一是针对程序格式和排版方面的建议；二是从实践中总结出来的有利于提高代码可读性的经验；三是切实提高代码质量，避开C++陷阱的方法。
尽管其建议的一些规则在不少读者，尤其是编程老手看来是理所当然的。比如：规则13：用“UpperCamelCase”拼写类、常量、结构枚举和typedef名；规则80：将全局函数、全局变量和常量声明为类的静态成员。但这本书的读者群并非只针对为觅得一席之地苦苦挣扎的新手，书中有些规则，即便对于编程经验丰富的老手来说，也常常被忽略，但是却切实可行地提高了代码质量。比如：规则82：用枚举类型代替布尔量以提高代码的可读性。规则103：声明保护或私有的析构函数以阻止静态分配和自动分配。规则104：用explicit声明单参数构造函数，以避免错误的隐式类型转换。
这本书短小精悍，和众多原版书的译本相似，附录中单列出了摘要部分和术语部分，前者是全书规则的汇总，便于阅读之后的复习、查阅。后者则给那些看多了中文书籍而对专业名词的英文写法十分陌生的菜鸟们一次补课的良机。
若你对我这样不遗余力地推荐本书并强调编程风格的重要性仍然存有疑虑，请听我说一个不久前听到的故事。故事的讲述者是美国著名软件公司的顶梁柱，他用这个故事来提醒我们这些新人，必须重视文档约定和打包约定，否则这样的事会在我们身上重现。
十年前，意气风发的他成为某公司软件开发团队的一员，凭借优秀的编码能力和开朗的性格很快取得了大家的信任并融入了团队。他被要求将一个版本的代码merge到另一个版本上去，安排工作的人告诉他，没什么需要特别注意的，只要改变版本号就行。他迅速完成，由于简单，整个团队也忽略了codere鄄view这一环节，而这部分代码最终被发布。一天清晨，电话炸起，他被告知，checkin的代码造成了200万人次的Email用户登录失败，已经被紧急撤回。后果非常严重，但原因却极为简单，这两个版本还存在一个区别，就是账户登录连接时间这个变量上，前个版本以毫秒为单位，而后一个以纳秒为单位。尽管他所在公司没有追究他的责任，因为这件事确实也很难分清责任，但即便是十年以后，我依旧可以从他脸上看到当初接到电话那一霎的骇然。
所以，翻烂了大部头经典名著的你，或许少的只是薄薄的这一本――《The Elements of C++ Style》(《C++编程风格》)。
(《C++编程风格》,［美］米斯菲尔特等著，罗小平译，人民邮电出版社，2008年10月第一版，29.00元）
 |
