微软资深软件工程师：阅读代码真的很难(2)

导读：原文作者 Eric Lippert 是微软一名资深软件设计工程师，从1996年起一直在微软开发部门任职，协助设计并实现VBScript、JScript、JScript .NET、Windows Script Host、Visual Studio Tools for Office 和 C#。 这篇文章是《阅读代码真的很难》的续文。

昨天，我对于这个问题思考了好一会，还跟Larry Osterman进行了讨论，终于想出了一些也许会在阅读和调试别人的代码时有用的建议。

首先，你正在调试的机器代码，很有可能会与源代码不匹配，或者只是因为你得到的源代码不是最新的，或者是因为代码被过度优化以至于源代码和二进制文件之间的关系变得不够明显——像瑞士乳酪那样松散，又或者是因为你遇到符号表错误等等。我当然不是个汇编程序员，但我了解必要的汇编知识和调用规则，这样我可以试着调试那些源代码和二进制之间不是那么同步的代码。即使知道“‘this”指针很有可能在ECX寄存器中”可以对正在进行的调试会话大有帮助。

第二，你还记得那部卡通片Calvin and Hobbes中Calvin偷偷溜到Hobbes的身后吓他，然后学到了吓一只正在睡觉的老虎并不明智吗？Calvin喃喃自语道：“我得开始聆听那没有声音却不停冒出的疑问才行。”

那部卡通片改变了我的生活。我意识到自己常常会犯一个错误，在回顾之前我应该能够提前意识到，但不知因为什么，我却不顾没有声音却不停冒出的疑问而执意地冒失地继续下去。我决定绝不让自己的墓碑上写着“此人死于愚蠢的但本可以完全避免的事情上。”

相信你的头脑。是的，预感有可能是错的，但当它真的是错误的时候，发现它是错的并不需要很大的代价。而如果它是对的，你可以省很多时间。当我在调试我不知道的代码时，我试着去聆听那些没有声音却不停冒出的疑问。在内存显示窗口有一个字节瞬间变成了红色，表明它已经改变了。嗯。在这次函数调用中我是否期望内存发生改变？其自身拥有的内存是改变了，还是只是堆栈错误？嗯，这个局部变量突然变值—这是不是个符号错误？这个变量是否是shadow变量而我则刚刚离开了内部作用域？顺着这类的线索追踪下去。

译者注：shadow变量：当一个变量所在的作用域之外还有一个同名的变量，称为shadow变量；shadow变量只在自己的作用域有效，详细解释和示例参见variable shadowing.

Eric Lippert

最近我凭直觉在Excel中找到了一个极不起眼的漏洞—我有发现有一个数位的堆分配的缓冲器通过了一个函数但其长度没有通过。嗯。可疑！果真，只要你追踪所有的逻辑，你就会发现更深十级的函数对于缓冲范围作了错误的假设并且造成了一个错误。幸好这个假设十分保守，受到了许多限制，所以没有造成缓冲溢出的后果。还有，幸好这个漏洞极不起眼—一般用户都不会马上就陷入其中。

那么我的第三个建议又会是什么呢？昨天我说过，你需要知道代码是干什么的和开发者为什么要让它干这些。但你还需要知道更多信息—你还要知道代码是怎样随着时间的流逝而在发生改变的。显然在这个漏洞中，程序一开始占用一小块固定大小的缓冲。有人修改了缓冲区分配代码以分配可变范围的缓冲区，但却忘记了这代码所表示的程序是写来假定一个固定的小范围缓冲的。漏洞的发生通常由于在其它合理的代码重整中发生的极小的错误。明显地，没有人会把这样的漏洞写进从一开始就已经有了可变范围的缓冲区代码的代码。当你在阅读一片段的代码时，试着了解不变量将会是什么，然后想想那些情况会违反常量的假定。

当然，要想知道那些没有声音却不停冒出的疑问来自哪里是很困难的，而且可能教也教不来。不管你怎样试图克服它，它都会很困难。