思维惯性引发的编程问题

为什么程序要了解思维的障碍，并要练习有意识的加以克服？这里举一个实际发生的问题。

写代码像写作一样，有时思如泉涌，顺着思路就把一段代码写得有模有样。

下面是一个状态码检查的例子(这种写法本身并不严谨，但这里要讨论是一个更为严重的问题.)：

typedef enum {   STATE_DEFAULT,   STATE_A = 1,   STATE_B = 2,   STATE_C = 4} STATE_ITEM;

// state为获得的状态
 if (STATE_A & state)
 {
 }
 else if (STATE_B & state)
 {
 }
 else if (STATE_C & state)
 {
 }

这样很自然就有了一个模型STATE & state就可以判断是不是当前这个状态。 顺着前面的思路，就有了：

 if (STATE_DEFAULT & state)
 {
   ...
 }

一切看起来都合情合理，程序员这时往往是很难会想到要回头检查的(至少我是这样)。于是一个Bug就在不久之后被发现了! 因为 STATE_DEFAULT & state永远为0!

而解决方案有两个: 1.将设计用图形化的先表现出来，即使只是在纸上画一下。2.代码走查，特别注意边界条件，可以是自己回头查一下，也可以类似结对编程一样，请同伴帮助走查。但最起码的是，程序员要意识到这种问题的存在。这就是本文的目的。

转载请注明出处: http://blog.csdn.net/horkychen