这是一本老书，作者 Steve Maguire 在微软工作期间写了这本书，英文版于 1993 年发布。2013 年推出了 20 周年纪念第二版。我们看到的标题是中译版名字，英文版的名字是《Writing Clean Code ─── Microsoft’s Techniques for Developing》，这本书主要讨论如何编写健壮、高质量的代码。作者在书中分享了许多实际编程的技巧和经验，旨在帮助开发人员避免常见的编程错误，提高代码的可靠性和可维护性。

---

不记录，等于没读。本文记录书中第七章内容：编码中的假象。

---

有些编程实践非常危险，永远不应使用。它们中的大多数明显具有风险，但也有些看似相当安全，甚至令人向往，因为它们满足需求而没有明显的危险。这些危险的编码实践其实是披着羊皮的狼。为什么不应该引用刚刚释放的内存？为什么在全局或静态存储中传递数据是有风险的？为什么应该避免寄生函数？为什么依赖 ANSI 标准中列出的每一个细枝末节是不明智的？

这里先解释 寄生函数。在编程领域，“parasitic functions”（寄生函数）通常指那些依赖外部状态或副作用而工作的函数。这些函数不具备独立性，因为它们的行为依赖于外部环境，而不是纯粹的输入参数。这样的函数往往难以预测、测试和维护。以下是寄生函数的一些典型特征：

• 依赖全局变量：函数依赖于全局变量的状态，这使得它们在不同的上下文中表现不一致。
• 修改外部状态：函数在运行时改变了外部变量或状态，而不仅仅是返回一个结果。
• 副作用：函数除了返回值外，还对程序的其他部分产生影响，如打印输出、修改文件等。
• 依赖环境：函数的行为依赖于外部环境或系统状态，如系统时间、配置文件等。

寄生函数的存在会增加代码的复杂性和错误率，因为它们不遵循“单一职责原则”（SRP）和“函数纯度”（pure function）的理念。为了提高代码的可维护性和可靠性，编程时应尽量避免使用寄生函数，而应设计独立、可预测和易于测试的函数。

注意到底引用了什么

memchr 函数的作用是在内存块中查找第一次出现的特定字符。如果在内存块中找到了该字符，则返回指向该字符的指针，否则，返回 NULL 。一个正确的实现代码如下所示：

void *memchr(void *pv, unsigned char ch, size_t size) {
	unsigned char *pch = (unsigned char *)pv;
	while(size-- > 0)
	{
		if(*pch == ch)
			return(pch);
			
		pch++;
	}
	
	return(NULL);
}

如果有程序员想要追求更快的速度，那么他可以使用一些奇技淫巧来去除范围检查：只要在内存块之后的第一个位置存放 ch 字符，这样总是可以找到 ch 字符。只要能保证总是可以找打指定字符，那么就可以不用检查内存范围(这个内存范围内一定有待查字符)。或许你会有疑问，在内存块之后放置一个字符，不是破坏其它内存数据了吗？是的，但是有办法补救，我们会先将这个位置数据存储下来，在函数返回前，再将数据放回原位置，堪称完美。代码如下：

void *memchr(void *pv, unsigned char ch, size_t size) {
	unsigned char *pch = (unsigned char *)pv;
	unsigned char *pchPlant;
	unsigned char chSave;			

	pchPlant = pch + size;	//pchPlant 指向要被查寻的内存块后面的第一个字节
	chSave = *pchPlant;		//保存这个区域的数据
	*pchPlant = ch;			//设置数据位 ch ，确保函数一定能找到 ch
	
	while(*pch != ch)
		pch++;
		
	*pchPlant = chSave;		//恢复数据
	
	return((pch == pchPlant)? NULL : pch);
}

巧妙吗？通过保证 memchr 总能找到 ch，这样就可以删除范围检查，使循环速度加倍。但是这样可靠吗？

并不可靠。这少有以下问题：

• 如果 pv 指向的是只读存储器，那么在 pchPlant 处存放字符 ch 就不起作用。
• 如果 pchPlant 指向映射到 I/O 的存储器，那么向该位置写操作的后果就不可预测。
• 如果待查找的内存块恰好位于合法内存的最后位置，那么 pchPlant 指向非法区域，向这个位置写操作会引起存储故障，可能会终止整个程序。
• 如果 pchPlant 指向并发进程共享的数据区域，则可能造成其它进程数据错误。

不要引用不属于你自己的存储空间！

再看一个有些微妙的错误的例子：释放链表的子窗口。代码简化如下：

void FreeWindowsTree(windows *pwndRoot) {
	if(pwndRoot != NULL) {
		window *pwnd;
		
		for(pwnd = pwndRoot->pwndChild; pwnd != NULL; pwnd = pwnd->pwndSibling)
			FreeWindowTree(pwnd);	//释放子窗口
		...
	}
}

让我们看一下 for 循环体，它按照以下步骤执行：

1. 初始化 pwnd ：pwnd = pwndRoot->pwndChild;
2. 判断条件： pwnd 是否为 NULL 。如果是，执行步骤 3；否则循环结束。
3. 执行函数 FreeWindowTree(pwnd) ：释放 pwnd 指向的存储块。
4. 更新 pwnd ：pwnd = pwnd->pwndSibling，然后执行步骤 2。

问题出现在步骤 4 上。更新 pwnd 时，表达式 pwnd->pwndSibling 引用了已经释放的内存数据。有些程序员并不认为这样有什么问题，刚刚存储区还好好的，也没做什么影响它的事，而且在机器上运行这个程序，并有任何的异常。

关键的是，一旦释放 pwnd 指向的内存块，那么 pwnd->pwndSibling 的值是什么呢？是一堆垃圾。引用已经释放的存储区是非法的，在释放过程中，存储管理程序可能以任何方式使用这些内存，而你并不能控制存储管理程序，因为它是操作系统提供的。如果上述程序能正常运行，也只是凑巧而已。

仅取所需

编写一个无符号数转字符串的函数，一般步骤是：

1. 获取数字的个位数，转换成字符
2. 将数字缩小 10 倍
3. 判断数字是否大于 0 ，如果是，执行步骤1，否则转换完成。

唯一的问题是，这样转换出来的字符串是倒置的，比如数字 123，通过上述算法得到的字符串是 “321”。所以，为了获取正确的顺序，转换结束后要进行字符串反转操作。有些程序员觉得这样做效率低下，他们给出了新的算法，反向生成字符串，以便正确表示数字，代码如下：

char *UnsToStr(unsigned u, char *str)  { 
   char *pch; 

   ASSERT(u <= 65536); 

   pch = &str[5]; 		//这里假设 str 指向的内存足够大,能存储 u 的最大值
   *pch = '\0'; 

   do 
   	*--pch = u % 10 + '0'; 
   while((u /= 10) > 0); 

   return pch; 
}

这个函数的问题是，str 指向的存储区有多大，你并不知道。但是，函数却假设它足够大。调用者并不一定知道这个函数基于的假设。比如调用者确定自己的数据在 0-255 以内，就可能只申请 4 个字节的内存空间：

char strScore[4]; 
UnsToStr(UserScore, strScore); 	

这样 UnsToStr 函数会破坏 strScore 数组后面的内存数据。一个编程经验是：尽一切可能避免依赖。你的每一个依赖都可能是将来问题的原因。

不要在全局或静态存储中传递数据

还是以编写一个无符号数转字符串的函数为例。在上一节中，我们说不能假设 str 指向的存储区足够大。所以这次，我们在函数内部定义一个足够大的静态数组：

char *strFromUns(unsigned u) {
	static char strDigits[] = "?????" ; 	//5个字符 + '\0'
	char *pch;
	ASSERT(u <= 65535);
	
	pch = &strDigits[5];
	ASSERT(*pch == '\0');
	do
		*--pch = u % 10 + '0' ;
	while((u /= 10) > 0);
	
	return(pch);
}

一旦使用全局或静态存储区传递数据，就意味着这个函数不具备可重入性。比如连续将两个无符号数转换成在字符串：

strHighScore = strFromUns(HighScore);
strThisScore = strFromUns(Score);

第二次调用会将第一次转换的结果覆盖掉！

一些观点

• 任何时候，只要不编写直观代码，就是自找麻烦！

• 用一把螺丝刀撬开油漆罐的盖子，然后又用这把螺丝刀搅拌油漆，这是家庭维护中最熟悉的举动之一。人们知道这样做会损坏螺丝刀，不应该如此，为什么还要用螺丝刀来搅拌油漆呢？原因在于，这样做在当时很方便，而且能够解决问题。

• 使用过某个工具后，你有把它物归原位的习惯吗？据我观察，基本上没有人这么做。所以等到再次用到这个工具的时候，他们会费时间到处找。为什么不放回原位呢，因为用完一扔最方便。
  我很警惕那些怎么方便就怎么来的人。他们常常会以牺牲他人的方式方便自己。

• 在 Microsoft，那些理解产品内部工作原理的人，会更多的编写新代码。对项目了解很少的人则把时间花在阅读别人的代码、修改别人的BUG以及对已有功能做少量的局部性增补。这种安排很有意义。如果你不理解系统，就不能给系统增加主要功能。

• 如果你发现自己编写的代码用了较多技巧，那么停止编写代码并寻找别的解决方法。如果一个算法不直观，却产生了正确的结果，那么这个算法的错误同样也会不明显。因此，编写直观代码才是真正的聪明人。

小结

• 如果你在处理不属于你的数据，哪怕是临时的，也不要写入它。虽然你可能认为读取数据总是安全的，但请记住，读取内存映射的 I/O 可能会对硬件造成危害。
• 一旦释放了内存，不要再引用它。引用已释放的内存会导致许多种错误。
• 为了效率，你可能会想在全局或静态缓冲区中传递数据，但这是一个充满危险的捷径。如果你编写了一个函数，它所创建的数据只对调用者有用，请将数据返回给调用者，或者保证你不会意外地更改这些数据。
• 不要编写依赖于其他函数具体实现的函数。
• 编程时，按照程序设计语言原来的本意，编写清晰、准确的代码。避免使用可疑的编程习惯，即使语言标准保证它们能工作。记住，标准是会改变的。
• 从逻辑上看，用 C 语言高效地表达一个概念似乎也会生成同样高效的机器代码，但事实并非如此。在将一段清晰的多行 C 代码压缩成单行代码之前，请确保你因此得到了更好的机器代码。即便如此，请记住局部效率的提升通常难以察觉，而且通常不值得破坏代码的可读性。
• 最后，不要像律师写合同那样编写代码。如果一个普通程序员不能阅读和理解你的代码，那它就太复杂了；请使用更简单的语言。

---

每一份打赏，都是对创作者劳动的肯定与回报。！