按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
（1）知错就改；
（2）经常温故而知新；
（3）坚持学习，天天向上。
二、本书导读
首先请做附录B的C＋＋/C试题（不要看答案），考查自己的编程质量究竟如何。然后参照答案严格打分。
（1）如果你只得了几十分，请不要声张，也不要太难过。编程质量差往往是由于不良习惯造成的，与人的智力、能力没有多大关系，还是有药可救的。成绩越差，可以进步的空间就越大，中国不就是在落后中赶超发达资本主义国家吗？只要你能下决心改掉不良的编程习惯，第二次考试就能及格了。
（2）如果你考及格了，表明你的技术基础不错，希望你能虚心学习、不断进步。如果你还没有找到合适的工作单位，不妨到上海贝尔试一试。
（3）如果你考出85分以上的好成绩，你有义务和资格为你所在的团队作〃C＋＋/C编程〃培训。希望你能和我们多多交流、相互促进。半年前我曾经发现一颗好苗子，就把他挖到我们小组来。
（4）如果你在没有任何提示的情况下考了满分，希望你能收我做你的徒弟。
编程考试结束后，请阅读本书的正文。
本书第一章至第六章主要论述C＋＋/C编程风格。难度不高，但是细节比较多。别小看了，提高质量就是要从这些点点滴滴做起。世上不存在最好的编程风格，一切因需求而定。团队开发讲究风格一致，如果制定了大家认可的编程风格，那么所有组员都要遵守。如果读者觉得本书的编程风格比较合你的工作，那么就采用它，不要只看不做。人在小时候说话发音不准，写字潦草，如果不改正，总有后悔的时候。编程也是同样道理。
第七章至第十一章是专题论述，技术难度比较高，看书时要积极思考。特别是第七章〃内存管理〃，读了并不表示懂了，懂了并不表示就能正确使用。有一位同事看了第七章后觉得〃野指针〃写得不错，与我切磋了一把。可是过了两周，他告诉我，他忙了两天追查出一个Bug，想不到又是〃野指针〃出问题，只好重读第七章。
光看本书对提高编程质量是有限的，建议大家阅读本书的参考文献，那些都是经典名著。
如果你的编程质量已经过关了，不要就此满足。如果你想成为优秀的软件开发人员，建议你阅读并按照CMMI规范做事，让自己的综合水平上升一个台阶。上海贝尔的员工可以向网络应用事业部软件工程研究小组索取CMMI有关资料，最好能参加培训。
三、版权声明
本书的大部分内容取材于作者一年前的书籍手稿（尚未出版），现整理汇编成为上海贝尔网络应用事业部的一个规范化文件，同时作为培训教材。
由于C＋＋/C编程是众所周知的技术，没有秘密可言。编程的好经验应该大家共享，我们自己也是这么学来的。作者愿意公开本书的电子文档。
版权声明如下：
（1）读者可以任意拷贝、修改本书的内容，但不可以篡改作者及所属单位。
（2）未经作者许可，不得出版或大量印发本书。
（3）如果竞争对手公司的员工得到本书，请勿公开使用，以免发生纠纷。
预计到2002年7月，我们将建立切合中国国情的CMMI 3级解决方案。届时，包括本书在内的约1000页规范将严格受控。
欢迎读者对本书提出批评建议。
林锐，2001年7月
第1章 文件结构
每个C＋＋/C程序通常分为两个文件。一个文件用于保存程序的声明（declaration），称为头文件。另一个文件用于保存程序的实现（implementation），称为定义（definition）文件。
C＋＋/C程序的头文件以〃。h〃为后缀，C程序的定义文件以〃。c〃为后缀，C＋＋程序的定义文件通常以〃。cpp〃为后缀（也有一些系统以〃〃或〃。cxx〃为后缀）。
1。1 版权和版本的声明
版权和版本的声明位于头文件和定义文件的开头（参见示例1…1），主要内容有：
（1）版权信息。
（2）文件名称，标识符，摘要。
（3）当前版本号，作者/修改者，完成日期。
（4）版本历史信息。
/*
* Copyright （c） 2001；上海贝尔有限公司网络应用事业部
* All rights reserved。
*
* 文件名称：filename。h
* 文件标识：见配置管理计划书
* 摘 要：简要描述本文件的内容
*
* 当前版本：1。1
* 作 者：输入作者（或修改者）名字
* 完成日期：2001年7月20日
*
* 取代版本：1。0
* 原作者 ：输入原作者（或修改者）名字
* 完成日期：2001年5月10日
*/
示例1…1 版权和版本的声明
1。2 头文件的结构
头文件由三部分内容组成：
（1）头文件开头处的版权和版本声明（参见示例1…1）。
（2）预处理块。
（3）函数和类结构声明等。
假设头文件名称为 graphics。h，头文件的结构参见示例1…2。
* 【规则1…2…1】为了防止头文件被重复引用，应当用ifndef/define/endif结构产生预处理块。
* 【规则1…2…2】用 #include 格式来引用标准库的头文件（编译器将从标准库目录开始搜索）。
* 【规则1…2…3】用 #include 〃filename。h〃 格式来引用非标准库的头文件（编译器将从用户的工作目录开始搜索）。
* 【建议1…2…1】头文件中只存放〃声明〃而不存放〃定义〃
在C＋＋ 语法中，类的成员函数可以在声明的同时被定义，并且自动成为内联函数。这虽然会带来书写上的方便，但却造成了风格不一致，弊大于利。建议将成员函数的定义与声明分开，不论该函数体有多么小。
* 【建议1…2…2】不提倡使用全局变量，尽量不要在头文件中出现象extern int value 这类声明。
// 版权和版本声明见示例1…1，此处省略。
#ifndef GRAPHICS_H // 防止graphics。h被重复引用
#define GRAPHICS_H
#include // 引用标准库的头文件
。。。
#include 〃myheader。h〃 // 引用非标准库的头文件
。。。
void Function1（。。。）； // 全局函数声明
。。。
class Box // 类结构声明
｛
。。。
｝；
#endif
示例1…2 C＋＋/C头文件的结构
1。3 定义文件的结构
定义文件有三部分内容：
（1） 定义文件开头处的版权和版本声明（参见示例1…1）。
（2） 对一些头文件的引用。
（3） 程序的实现体（包括数据和代码）。
假设定义文件的名称为 graphics。cpp，定义文件的结构参见示例1…3。
// 版权和版本声明见示例1…1，此处省略。
#include 〃graphics。h〃 // 引用头文件
。。。
// 全局函数的实现体
void Function1（。。。）
｛
。。。
｝
// 类成员函数的实现体
void Box：：Draw（。。。）
｛
。。。
｝
示例1…3 C＋＋/C定义文件的结构
1。4 头文件的作用
早期的编程语言如Basic、Fortran没有头文件的概念，C＋＋/C语言的初学者虽然会用使用头文件，但常常不明其理。这里对头文件的作用略作解释：
（1）通过头文件来调用库功能。在很多场合，源代码不便（或不准）向用户公布，只要向用户提供头文件和二进制的库即可。用户只需要按照头文件中的接口声明来调用库功能，而不必关心接口怎么实现的。编译器会从库中提取相应的代码。
（2）头文件能加强类型安全检查。如果某个接口被实现或被使用时，其方式与头文件中的声明不一致，编译器就会指出错误，这一简单的规则能大大减轻程序员调试、改错的负担。
1。5 目录结构
如果一个软件的头文件数目比较多（如超过十个），通常应将头文件和定义文件分别保存于不同的目录，以便于维护。
例如可将头文件保存于include目录，将定义文件保存于source目录（可以是多级目录）。
如果某些头文件是私有的，它不会被用户的程序直接引用，则没有必要公开其〃声明〃。为了加强信息隐藏，这些私有的头文件可以和定义文件存放于同一个目录。
第2章 程序的版式
版式虽然不会影响程序的功能，但会影响可读性。程序的版式追求清晰、美观，是程序风格的重要构成因素。
可以把程序的版式比喻为〃书法〃。好的〃书法〃可让人对程序一目了然，看得兴致勃勃。差的程序〃书法〃如螃蟹爬行，让人看得索然无味，更令维护者烦恼有加。请程序员们学习程序的〃书法〃，弥补大学计算机教育的漏洞，实在很有必要。
2。1 空行
空行起着分隔程序段落的作用。空行得体（不过多也不过少）将使程序的布局更加清晰。空行不会浪费内存，虽然打印含有空行的程序是会多消耗一些纸张，但是值得。所以不要舍不得用空行。
* 【规则2…1…1】在每个类声明之后、每个函数定义结束之后都要加空行。参见示例2…1（a）
* 【规则2…1…2】在一个函数体内，逻揖上密切相关的语句之间不加空行，其它地方应加空行分隔。参见示例2…1（b ）
// 空行
void Function1（。。。）
｛
。。。
｝
// 空行
void Function2（。。。）
｛
。。。
｝
// 空行
void Function3（。。。）
｛
。。。
｝
// 空行
while （condition）
｛
statement1；
// 空行
if （condition）
｛
statement2；
｝
else
｛
statement3；
｝
// 空行
statement4；
｝
示例2…1（a） 函数之间的空行 示例2…1（b） 函数内部的空行
2。2 代码行
* 【规则2…2…1】一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅读，并且方便于写注释。
* 【规则2…2…2】if、for、while、do等语句自占一行，执行语句不得紧跟其后。不论执行语句有多少都要加｛｝。这样可以防止书写失误。
示