Microsoft的无错C编程秘籍：编写优质C程序策略

需积分: 3 193 浏览量更新于2024-09-28 收藏 1.35MB PDF 举报

《C语言编程精粹: Writing Clean Code – Microsoft Techniques for Developing Bug-free C Programs》是一本由Steve Maguire所著的专业书籍，由姜静波、佟金荣翻译，麦中凡校审，由电子工业出版社出版。该书主要介绍Microsoft内部编写高质量、低错误率C语言程序的最佳实践，强调了编写整洁代码的重要性，旨在帮助程序员避免常见错误，提高代码可读性和可维护性。书中的内容涵盖了多个关键主题，如： 1. **假想的编译程序**：通过构建一个理想化的编译器视角，指导读者理解代码如何被编译和执行，从而提升对程序行为的理解。 2. **自我保护机制**：如第2章的断言技术，鼓励程序员在代码中设置条件检查，以及时发现潜在问题。 3. **子系统防护**：第3章讲解如何为程序的不同部分设置防御机制，防止错误扩展到整个系统。 4. **代码审查与调试**：第4章介绍逐条跟踪技术，以及第5章的糖果机界面示例，展示了如何有效地诊断和修复问题。 5. **风险评估与管理**：第6章讨论了编程过程中的风险识别与应对策略，帮助开发者预见潜在的风险点。 6. **隐藏的陷阱与假象**：第7章深入剖析编码中的常见误区，提醒读者注意那些看似无害但实际上可能导致问题的编码习惯。 7. **态度决定一切**：第8章强调了编写干净代码的态度，即编写简洁、清晰、可维护的代码，这是编写无错程序的关键。 8. **附录**：提供了一系列实用工具，如编码检查表、内存管理例程和练习答案，有助于读者巩固所学并进行自我测试。该书不仅适用于C语言初学者，也适合经验丰富的开发人员提升代码质量，遵循Microsoft的内部标准，减少bug，提升项目成功率。同时，由于是多人协作整理，部分章节可能存在代码风格差异，但整体上保持了原著的严谨性和实用性。对于任何关注代码品质和性能的C程序员来说，这本书都是宝贵的学习资料。

能够亮相。“噢，不！我们测试人员的工作可不这么简单，我们还要使用代码覆盖工具、自

动的测试集、随机的“猴”程序、抽点打印或其他什么的”。也许是这样，但还是让我们来看

看这些工具究竟做了些什么吧！覆盖分析工具能够指明程序中哪些部分未被测试到，测试

人员可以使用这一信息派生出新的测试用例。至于其它的工具无非都是“输入数据、观察结

果”这一策略的自动化。

请不要产生误解，我并不是说测试人员的所作所为都是错误的。我只是说利用黑箱方法

所能做的只是往程序里填数据，并看它弹出什么。这就好比确定一个人是不是疯子一样。问

一些问题，得到回答后进行判断。但这样还是不能确定此人是不是疯子。因为我们没法知道

其头脑中在想些什么。你总会这样地问自己：“我问的问题够吗？我问的问题对吗……”。

因此，不要光依赖黑箱测试方法。还应该试着去模仿前面所讲的假想编译程序，来排除

运气对程序测试的影响，自动地抓住错误的每个机会。

考虑一下所用的语言

你最后一次看推销字处理程序的广告是什么时候？如果那个广告是麦迪逊大街那伙人

写的，它很可能是这么说：“无论是给孩子们的老师写便条还是为下期的《Great American

Novel》撰稿，WordSmasher 都能行，毫不费劲！WordSmasher 配备了令人吃惊的 233000 字

的拼写字典，足足比同类产品多 51000 个字。它可以方便地找出样稿中的打字错误。赶快到

经销商那里去买一份拷贝。WordSmasher 是从圆珠笔问世以来最革命性的书写工具！”。

用户经过不断地市场宣传熏陶，差不多都相信拼写字典越大越好，但事实并非如此。象

em、abel 和 si 这些词，在任何一本简装字典中都可以查到、但在 me、able 和 is 如此常见的

情况下您还想让拼写检查程序认为 em、abel 和 si 也是拼写正确的词吗？如果是，那么当你

看到我写的 suing 时，其本意很可能是与之风马牛不相及的 using。问题不在于 suing 是不

是一个真正的词而在于它在此处确实是个错误。

幸运的是，某些质量比较高的拼写检查程序允许用户删去象 em 这类容易引起麻烦的词。

这样一来，拼写检查程序就可以把原来合法的单词看成是拼写错误。好的编译程序也应该能

够这样 ─── 可以把屡次出错的合法的 C 习惯用法看成程序中的错误。例如，这类编译程

序能够检查出以下 while 循环错放了一个分号：

/* memcpy 复制一个不重叠的内存块 */

void* memcpy(void* pvTo, void* pvFrom, size_t size)

{

byte* pbTo = (byte*)pvTo;

虽然很清楚该程序是要将 ch 与水平制表符作比较，但实际上却成了对 ch 的赋值。对于

这种程序，编译程序当然不会产生错误，因为代码是合法的 C。

某些编译程序允许用户在 && 和 | | 表达式以及 if、for 和 while 构造的控制表达式

中禁止使用简单赋值，这样就可以帮助用户查出这种错误。这种做法的基本依据是用户极有

可能在以上五种情况下将等号＝＝偶然地健入为赋值号＝。

这种选择项并不妨碍用户作赋值，但是为了避免产生警告信息，用户必须再拿别的值，

如零或空字符与赋值结果做显式的比较。因此，对于前面的 strcpy 例子，若循环写成：

while(*pchTo++ = *pchFrom++)

NULL;

编译程序会产生警告信息一所以要写成；

while( (*pchTo++ = *pchFrom++)!=’ \0’ )

NULL;

这样做有两个好处。第一，现代的商用级编译程序不会为这种冗余的比较产生额外的代

码，可以将其优化掉。因此，提供这种警告选择项的编译程序是可以信赖的。第二，它可以

少冒风险，尽管两种都合法，但这是更安全的用法。

另一类错误可以被归入“参数错误”之列。例如，多年以前，当我正在学 C 语言时，曾

经这样调用过 fputc：

fprintf(stderr, “Unable to open file %s. \n”, filename);

……

fputc(stderr, ‘\n’);

这一程序看起来好象没有问题，但 fputc 的参数次序错了。不知道为什么，我一直认为

流指针（stderr）总是这类流函数的第一个参数。事实并非如此，所以我常常给这些函数传

递过去许多没用的信息。幸好 ANSI C 提供了函数原型，能在编译时自动地查出这些错误。

由于 ANSI C 标准要求每个库函数都必须有原型所以在 stdio.h 头文件中能够找到 fputc 的

原型。fputc 的原型是：

int fputc(int c, FILE* stream);

如果在程序中 include 了 stdio.h，那么在调用 fputc 时，编译程序会根据其原型对所

传递的每个参数进行比较。如果二者类型不同，就会产生编译错误。在上面的错误例于中，

因为在 int 的位置上传递了 FILE* 类型的参数，所以利用原型可以自动地发现前一个

fputc 的错误。

ANSI C 虽然要求标准的库函数必须有原型，但并不要求用户编写的函数也必须有原型。

严格地说，它们可以有原型，也可以没有原型。如果用户想要检查出自己程序中的调用错误，

必须自己建立原型，并随时使其与相应的函数保持一致。

最近我听到程序员在抱怨他们必须对函数的原型进行维护。尤其是刚从传统 C 项目转到

ANSI C 项目时，这种抱怨更多。这种抱怨是有一定理由的，但如果不用原型，就不得不依

赖传统的测试方法来查出程序中的调用错误。你可以扪心自问，究竟哪个更重要，是减少一

些维护工作量，还是在编译时能够查出错误？如果你还不满意，请再考虑一下利用原型可

以生成质量更好的代码这一事实。这是因为：ANSI C 标准使得编译程序可以根据原型信息

进行相应的优化。

在传统 C 中，对于不在当前正被编译的文件中的函数，编译程序基本上得不到关于它

的信息。尽管如此，编译程序仍然必须生成对这些函数的调用，而且所生成的调用必须奏效。

编译程序实现者解决这个问题的办法是使用标准的调用约定。这一方法虽然

奏效，但常常意味着编译程序必须生成额外的代码，以满足调用约定的要求。但如果使用了

“要求所有函数都必须有原型”这一编译程序提供的警告选择项，由于编

译程序了解程序中每个函数的参数情况，所以可以为不同的函数选择它认为最有效率的调

用约定。

空语句、错误的赋值以及原型检查只是许多 C 编译程序提供的选择项中的一小部分内容，

实际上常常还有更多的其它选择项。这里的要点是：用户可以选择的编译程序警告设施可以

就可能的错误向用户发出警告信息，其工作的方式非常类似于拼写检查程序对可能的拼写

错误的处理

Peter Lynch，据说是 80 年代最好的合股投资公司管理者，他曾经说过：投资者与赌

徒之间的区别在于投资者利用每一次机会，无论它是多么小，去争取利益；而赌徒则只靠

运气。用户应该将这一概念同样应用于编程活动，选择编译程序的所有可选警告设施，并把

这些措施看成是一种无风险高偿还的程序投资。再不要问：“应该使用这一警告设施吗？而

应该问：“为什么不使用这一警告设施呢？”。要把所有的警告开关都打开，除非有极好的

理由才不这样做。

使用编译程序所有的可选警告设施

增强原型的能力

不幸的是，如果函数有两个参数的类型相同，那么即使在调用该函数时互换了这两个

参数的位置，原型也查不出这一调用错误。例如，如果函数 memchr 的原型是：

void* memchr(const void* pv, int ch, int size);

那么在调用该函数时，即使互换其字符 ch 和大小 size 参数，编译程序也不会发出警告信

息。但是如果在相应界面和原型中使用了更加精确的类型，就可以增强原型提供的错误检查

能力。例如，如果有了下面的原型：

void* memchr(const void* pv, unsigned char ch, size_t size);

那么在调用该函数时弄反了其字符 ch 和大小 size 参数，编译程序就会给出警告错误。

在原型中使用更精确类型的缺陷是常常必须进行参数的显式类型转换，以消除类型不

匹配的错误，即使参数的次序正确。

lint 并不那么差

另一种检查错误更详细、更彻底的方法是使用 lint，这种方法几乎不费什么事。最初，

lint 这个工具用来扫描 C 源文件并对源程序中不可移植的代码提出警告。但是现在大多数

lint 实用程序已经变得更加严密，它不但可以检查出可移植性问题，而且可以检查出那些

虽然可移植并且完全合乎语法但却很可能是错误的特性，上一节那些可疑的错误就属于这

一类。

不幸的是，许多程序员至今仍然把 lint 看作是一个可移植性的检查程序，认为它只能

给出一大堆无关的警告信息。总之，lint 得到了不值得麻烦的名声。如果你也是这样想的程

序员，那么你也许应该重新考虑你的见解。想一想究竟是哪一种工具更加接近于前文所述的

假想编译程序，是你正使用的编译程序，还是 lint？

实际上，一旦源程序变成了没有 lint 错误的形式，继续使其保持这种状态是很容易做

到的。只要对所改变的部分运行 lint，没有错误之后再把其并入到原版源代码中即可。利用

这种方法，并不要进行太多的考虑，只要经过一、二周就可以写出没有 lint 错误的代码。在

达到这个程度时，就可以得到 lint 带来的各种好处了。

使用 lint 来查出编译程序漏掉的错误

剩余249页未读，继续阅读

mqfire

粉丝: 0
资源: 5

Microsoft的无错C编程秘籍：编写优质C程序策略

编程精粹 Writing Clean Code

编程精粹（Writing Clean Code）

单片机c语言编程入门教程

c语言编程技巧 chm

linux下c语言编程

信捷c语言编程教学视频

linux下c语言编程入门.pdf 网盘

c语言编程软件c语言编程软件

c语言编程题及其答案,c语言编程题目及答案.doc

三天打鱼两天晒网c语言编程

最新资源