编写清晰代码的艺术：Microsoft的bug-free程序开发技术

需积分: 9 18 浏览量更新于2024-07-29 收藏 1.32MB PDF 举报

"CleanCode" 《Clean Code》一书主要探讨了如何编写整洁、可读性强的代码，以及如何维护良好的编程习惯。书中的内容涵盖了软件工程中的多个方面，包括命名约定、错误处理、测试、代码组织等。作者强调代码的可读性和可维护性，认为这是提高软件质量的关键。 1. 命名约定：书中提到了微软的匈牙利命名法，这是一种在变量和函数名中嵌入类型信息的命名规范。例如，字符变量以"ch"开头，字节以"b"开头，长整型以"l"开头，指针则在其类型名前加"P"。这种命名方式可以帮助程序员快速理解代码中的数据类型。此外，作者还提倡在类型基础上添加有意义的标签，以区分不同用途的变量，如在处理字符串时，将字符指针命名为"str"。 2. 错误处理：书中提到了使用断言（assertion）来预防和检测程序错误，这是一种自我验证的手段，用于确保程序在关键点上的状态是正确的。作者建议在设计阶段就考虑错误处理，而不是等到出现问题时才去修复。 3. 子系统设防：这一部分可能涉及到如何构建模块化的系统，每个子系统都有明确的边界和职责，以减少错误传播和耦合度。作者可能会讨论如何通过设计良好的接口来保护子系统的内部实现，防止外部代码的不良影响。 4. 程序调试：书中提到的“逐条跟踪”可能是关于调试技术的讨论，如何通过单步执行代码来查找和解决问题。作者可能还会介绍一些有效的调试策略和工具。 5. 用户界面设计：糖果机界面可能作为一个案例，用来说明如何设计直观且易于使用的用户界面，同时保持代码的清晰和简洁。 6. 风险管理：这部分可能涉及软件开发中的风险管理，如何识别潜在的问题和风险，并采取措施来降低它们的影响。 7. 编码中的假象：这可能是指开发者在编程过程中常见的误解或陷阱，作者会提供一些避免这些错误的指导。 8. 态度问题：作者强调态度在编写干净代码中的重要性，包括对代码质量的执着追求，对团队协作的尊重，以及持续学习和改进的精神。 9. 附录：书中的附录包含了编码检查表，帮助开发者进行代码审查，内存日志例程，以及练习答案，以加深读者对概念的理解。通过《Clean Code》，作者鼓励开发者不仅仅关注代码的功能性，更应注重代码的可读性、可维护性和团队合作的效率。遵循这些原则，可以提高软件项目的成功率并降低长期维护成本。

assert(pvTo != NULL && pvFrom != NULL);

while(size-->0)

*pbTo++ == *pbFrom++;

return(pvTo);

}

aasert 是个只有定义了 DEBUG 才起作用的宏，如果其参数的计算结果为假，就中止调用

程序的执行。因此在上面的程序中任何一个指针为 NULL 都会引发 assert。

assert 并不是一个仓促拼凑起来的宏，为了不在程序的交付版本和调试版本之间引起重

要的差别，需要对其进行仔细的定义。宏 assert 不应该弄乱内存，不应该对未初始化的数据

进行初始化，即它不应该产主其他的副作用。正是因为要求程序的调试版本和交付版本行为

完全相同，所以才不把 assert 作为函数，而把它作为宏。如果把 assert 作为函数的话，其

调用就会引起不期望的内存或代码的兑换。要记住，使用 assert 的程序员是把它看成一个在

任何系统状态下都可以安全使用的无害检测手段。

读者还要意识到，一旦程序员学会了使用断言，就常常会对宏 assert 进行重定义。例如，

程序员可以把 assert 定义成当发生错误时不是中止调用程序的执行，而是在发生错误的位置

转入调试程序。assert 的某些版本甚至还可以允许用户选择让程序继续运行，就仿佛从来没

有发生过错误一样。

如果用户要定义自己的断言宏，为不影响标准 assert 的使用，最好使用其它的名字。本

书将使用一个与标准不同的断言宏，因为它是非标准的，所以我给它起名叫做 ASSERT，以使

它在程序中显得比较突出。宏 assert 和 ASSERT 之间的主要区别是 assert 是个在程序中可以

随便使用的表达式，而 ASSERT 则是一个比较受限制的语句。例如使用 assert，你可以写成：

if(assert(p != NULL), p->foo!=bar)

„„

但如果用 ASSERT 试试就会产生语法错误。这种区别是作者有意造成的。除非打算在表达

式环境中使用断言，否则就应该将 ASSERT 定义为语句。只有这样，编译程序才能够在它被错

误地用到表达式时产生语法错误。记住，在同错误进行斗争时每一点帮助都有助于错误的发

现。我们为什么要那些自己从来用不着的灵活性呢？

下面是一种用户自己定义宏 ASSERT 的方法：

#ifdef DEBUG

void _Assert(char* , unsigned); /* 原型 */

#define ASSERT(f) \

if(f) \

NULL; \

else \

_Assert(__FILE__ , __LINE__)

#else

#define ASSERT(f) NULL

#endif

从中我们可以看到，如果定义了 DEBUG，ASSERT 将被扩展为一个 if 语句。if 语句中的 NULL

语句让人感到很奇怪，这是因为要避免 if 不配对，所以它必须要有 else 语句。也许读者认

为在_Assert 调用的闭括号之后需要一个分号，但并不需要。因为用户在使用 ASSERT 时，已

经给出了一个分号.

当 ASSERT 失败时，它就使用预处理程序根据宏__FILE__和__LINE__所提供的文件名和行

号参数调用_Assert。_Assert 在标准错误输出设备 stderr 上打印一条错误消息，然后中止：

void _Assert(char* strFile, unsigned uLine)

{

fflush(stdout);

fprintf(stderr, “\nAssertion failed: %s, line %u\n”,strFile, uLine);

fflush(stderr);

abort();

}

在执行 abort 之前，需要调用 fflush 将所有的缓冲输出写到标准输出设备 stdout 上。

同样，如果 stdout 和 stderr 都指向同一个设备，fflush stdout 仍然要放在 fflush stderr

之前，以确保只有在所有的输出都送到 stdout 之后，fprintf 才显示相应的错误信息。

现在如果用 NULL 指针调用 memcpy，ASSERT 就会抓住这个错误，并显示出如下的错误信

息：

Assertion failed: string.c , line 153

这给出了 assert 与 ASSERT 之间的另一点不同。标准宏 assert 除了给出以上信息之外，还显

示出已经失败了的测试条件。例如对这个问题，我通常所用编译程序的 assert 会显示出如下

信息：

Assertion failed: pvTo != NULL && pbFrom != NULL

File string.c , line 153

在错误消息中包括测试表达式的唯一麻烦是每当使用 assert 时，它都必须为_Assert 产

生一条与该条件对应的正文形式打印消息。但问题是，编译程序要在哪儿存储这个字符串呢？

Macintosh、DOS 和 Windows 上的编译程序通常在全局数据区存储字符串，但在 Macintosh 上，

通常把最大的全局数据区限制为 32K，在 DOS 和 Windows 上限制为 64K。因此对于象 Microsoft

Word 和 Excel 这样的大程序，断言字符串立刻会占掉这块内存。

关于这个问题存在一些解决的办法，但最容易的办法是在错误信息中省去测试表达式字

符串。毕竟只要查看了 string.c 的第 153 行，就会知道出了什么问题以及相应的测试条件是

什么。

如果读者想了解标准宏 assert 的定义方法，可以查看所用的编译系统的 assert.h 文件。

ANSI C 标准在其基本原理部分也谈到了 assert 并且给出了一种可能的实现。P. J. Plauger

在其“The Standard C library”一书中也给出了一种略微不同的标准 assert 的实现。

不管断言宏最终是用什么样方法定义的，都要使用它来对传递给相应函数的参数进行确

认。如果在函数的每个调用点都对其参数进行检查，错误很快就会被发现。断言宏的最好作

用是使用户在错误发生时，就可以自动地把它们检查出来。

要使用断言对函数参数进行确认

“无定义”意味着“要避开”

如果读者停下来读读 ANSI C 中 memcpy 函数的定义，就会看到其最后一行说：“如果在存

储空间相互重叠的对象之间进行了拷贝，其结果无定义”。在其它的书中，对此的描述有点不

同。例如在 P. J. Plauger 和 Jim Brodie 的“Standard C”中相应的描述是：“可以按任何

次序访问和存储这两个数组的元素”。

总之，这些书都说如果依赖于以按特定方式工作的 memcpy，那么当使用相互重叠的内存

块凋用该函数时，你实际上是做了一个编译程序不同（包括同一编译程序的不同版本）、结果

可能也不同的荒唐的假定。

确实有些程序员在故意地使用无定义的特性，但我想大多数的程序员都会很有头脑地避

开任何的无定义特性。我们不应该效仿前一部分程序员。对于程序员来说，无定义的特性就

相当于非法的特征，因此要利用断言对其进行检查。倘若本想调用 memmove，却调用了 memcpy，

难道你不想知道自己搞错了吗？

通过增加一个可以验证两个内存块绝不重叠的断言，可以把 memcpy 加强如下：

/* memcpy ─── 拷贝不重叠的内存块 */

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

{

void* pbTo = (byte*)pvTo;

void* pbFrom = (byte*)pvFrom;

ASSERT(pvTo != NULL && pvFrom != NULL);

ASSERT(pbTo>=pbFrom+size || pbFrom>=pbTo+size);

while(size-->0)

*pbTo++ == *pbFrom++;

return(pvTo);

}

读者可能会认为上面的加强不大明显，怎么只用了一行语句就完成了重叠检查呢？其实

只要把两个内存块比作两辆在停车处排成一行等候的轿车，就可以很容易明白其中的道理。

我们知道，如果一辆车的后保险杠在另一辆车的前保险杠之前，两辆车就不会重叠。上面的

检查实现的就是这个思想，那里 pbTo 和 pbFrom 是两个内存块的“后保险杠”。PbTo+size 和

pbFrom+size 分别是位于其相应“前保险杠”之前的某个点。就是这么简单。

顺便说一句如果读者还没有认识到重叠填充的严重性，只要考虑 pbTo 等于 pbFrom+1 并

且要求至少要移动两个字节这一情况就清楚了。因为在这种情况下，memcpy 的结果是错误的。

所以从今以后，要经常停下来看看程序中有没有使用无定义的特性。如果程序中使用了

无定义的特性就要把它从相应的设计中去掉，或者在程序中包括相应的断言，以便在使用了

无定义的特性时，能够向程序员发出通报。

这种做法在为其他的程序员提供代码库（或操作系统）时显得特别重要。如果读者以前

曾经为他人提供过类似的库，就知道当程序员试图得到所需的结果时，他们会利用各种各样

的无定义特性。更大的挑战在于改进后新库的发行，因为尽管新库与老库完全兼容，但总有

半数的应用程序在试图使用新库时会产生瘫痪现象，问题在于新库在其“无定义的特性”方

面，与老库并不 100％兼容。

不要让这种事情发生在你的身上

在 1988 年晚些时候，Microsoft 公司的摇钱树 DOS 版 Word 被推迟了三个月，明显地影响

了公司的销售。这件事情的重要原因，是整整六个月来开发小组成员一直认为他们随时都可

以交出 Word。

问题出在 Word 小组要用到的一个关键部分是由公司中另一个小组负责开发的。这个小组

一直告诉 Word 小组他们的代码马上就可以完成，而且该小组的成员对此确信不疑。但他们没

有意识到的是在他们的代码中充斥了错误。

这个小组的代码与 Word 代码之间一个明显的区别是 Word 代码从过去到现在一直都使用

断言和调试代码，而他们的代码却几乎没有使用断言。因此，其程序员没有什么好的办法可

以确定其代码中的实际错误情况，错误只能慢慢地暴露出来。如果他们在代码中使用了断言，

这些错误本该在几个月之前就被检查出来。

大呼“危险”的代码

尽管我们已经到了新的题目，但我还是想再谈谈 memcpy 中的重叠检查断言。对于上面的

重叠检查断言：

ASSERT(pbTo>=pbFrom+size || pbFrom>=pbTo+size);

假如在调用 memcpy 时这个断言测试的条件为真，那么在发现这个断言失败了之后，如果

你以前从来没见过重叠检查，不知道它是怎么回事，你能想到发生的是什么差错吗？我想我

大概想不出来。但这并不是说上面的断言技巧性太强、清晰度不够，因为不管从那个角度看

这个断言都很直观。然而直观并不等于明显。

请相信我的话，很少比跟踪到了一个程序中用到的断言，但却不知道该断言的作用这件

事更令人沮丧的了。你浪费了大量的时间，不是为了排除错误，而只是为了弄清楚这个错误

到底是什么。这还不是事情的全部，更有甚者程序员偶尔还会设计出有错的断言。所以如果

搞不清楚相应断言检查的是什么，就很难知道错误是出现在程序中，还是出现在断言中。幸

运的是，这个问题很好解决，只要给不够清晰的断言加上注解即可。我知道这是显而易见的

事情，但令人惊奇的是很少有程序员这样做。为了使用户避免错误的危险，程序员们经历了

各种磨难，但却没有说明危险到底是什么。这就好比一个人在穿过森林时，看到树上钉着一

块上书“危险”红字的大牌子。但危险到底是什么？树要倒？废矿井？大脚兽？除非告诉人

们危险是什么或者危险非常明显，否则这个牌子就起不到帮助人们提高警觉的作用，人们会

忽视牌子上的警告。同样，程序员不理解的断言也会被忽视。在这种情况下，程序员会认为

相应的断言是错误的，并把它们从程序中去掉。因此，为了使程序员能够理解断言的意图，

要给不够清楚的断言加上注解。

如果在断言中的注解还注明了相应错误的其他可能解法，效果更好。例如在程序员使用

要从程序中删去无定义的特性

或者在程序中使用断言来检查出无定义特性的非法使用

剩余165页未读，继续阅读

hkx1n

粉丝: 119
资源: 208

编写清晰代码的艺术：Microsoft的bug-free程序开发技术

面向对象编程的Clean Code原则与实践

《Clean Code》敏捷软件工艺手册阅读指南

Clean Code Sorter: 提升代码可读性的Eclipse插件实现

Clean Code

cleanCode

Write Clean Code Write Clean Code Write Clean Code Write Clean Code

cleancode:leetcode的cleancode

cleanCode:这是TDD，CleanCode研究

Writing clean code

Writing Clean Code

最新资源