这是一本老书,作者 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 ,确保函数一定能找到 chwhile(*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
循环体,它按照以下步骤执行:
- 初始化
pwnd
:pwnd = pwndRoot->pwndChild; - 判断条件:
pwnd
是否为NULL
。如果是,执行步骤 3;否则循环结束。 - 执行函数
FreeWindowTree(pwnd)
:释放pwnd
指向的存储块。 - 更新
pwnd
:pwnd = pwnd->pwndSibling,然后执行步骤 2。
问题出现在步骤 4 上。更新 pwnd
时,表达式 pwnd->pwndSibling
引用了已经释放的内存数据。有些程序员并不认为这样有什么问题,刚刚存储区还好好的,也没做什么影响它的事,而且在机器上运行这个程序,并有任何的异常。
关键的是,一旦释放 pwnd 指向的内存块,那么 pwnd->pwndSibling 的值是什么呢?是一堆垃圾。引用已经释放的存储区是非法的,在释放过程中,存储管理程序可能以任何方式使用这些内存,而你并不能控制存储管理程序,因为它是操作系统提供的。如果上述程序能正常运行,也只是凑巧而已。
仅取所需
编写一个无符号数转字符串的函数,一般步骤是:
- 获取数字的个位数,转换成字符
- 将数字缩小 10 倍
- 判断数字是否大于 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 代码压缩成单行代码之前,请确保你因此得到了更好的机器代码。即便如此,请记住局部效率的提升通常难以察觉,而且通常不值得破坏代码的可读性。
- 最后,不要像律师写合同那样编写代码。如果一个普通程序员不能阅读和理解你的代码,那它就太复杂了;请使用更简单的语言。
每一份打赏,都是对创作者劳动的肯定与回报。!