程序员修炼之路-(1)基础(下)：正确性证明

来自《Writing Solid Code》的一则小故事，Donald Knuth在其著名的排版软件TEX的封面上写到：“I believe that the final bug in TEX was discovered and removed on November 27, 1985. But if, somehow, an error still lurks in the code, I shall gladly pay a finder 's fee of $20.48 to the first person who discovers it.”（我相信TEX的最后一个bug已经在1985年11月27日发现被移除。但是如果代码中仍有错误，我将高兴地支付第一个发现的人20.48美元的报酬。）

这个故事重要的一点，不是Knuth最终是否支付了谁20.48美元，而是他对自己代码的质量的自信。你认识的程序员中有多少人能自信地说他们的程序是零bug的？又有多少能发表这样的声明并支付费用？

1 为何要证明代码是正确的？

《Programming Pearls》的第四章里讲到，证明程序的正确性给了程序员表达自己对代码深入理解的机会。而《The Science of Programming》一书则用了开篇一章来解答这个问题。下面通过一小段代码来解释代码正确性的重要性。

这段代码是在没有整数除法运算器的环境中计算商和余数。为了验证程序的正确性，我们加上一些输出语句，但这会导致大量的输出和人工比较工作。于是我们将输出改为断言，即当出错时才会输出并停止程序。对于这一小段程序，前置断言是y(除数)大于0，后置断言是x = y*q + r (q商，r余数)。

 

这一小段代码看起来没有什么问题，直到有一天你看到了下面这样的运行结果，花费一整天来查找错误的原因：

x = 6，y = 3，q = 1，r = 3

问题就在于，余数r应该小于除数y。也就是说我们循环的条件应该是r >= y而不是r > y。其实如果我们的后置断言足够强的话，我们是可以省掉这浪费掉的一整天的查错工作的。

 

接着某天你又碰到了r = -2的运行结果，因为被除数是负数，也就是说我们的前置断言也不够强。我们本可以早些捕捉到这些错误并节省掉两天的查错时间，我们要做的只是让前置和后置断言足够强！然而我们为什么没考虑到这些条件？

 

一定要不断地试错才能完善吗？我们的问题在于对代码段要做的事没有细心