为什么程序要了解思维的障碍，并要练习有意识的加以克服？这里举一个实际发生的问题。
写代码像写作一样，有时思如泉涌，顺着思路就把一段代码写得有模有样。
下面是一个状态码检查的例子(这种写法本身并不严谨，但这里要讨论是一个更为严重的问题.)：
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)
{
...
}
而解决方案有两个: 1.将设计用图形化的先表现出来，即使只是在纸上画一下。2.代码走查，特别注意边界条件，可以是自己回头查一下，也可以类似结对编程一样，请同伴帮助走查。但最起码的是，程序员要意识到这种问题的存在。这就是本文的目的。
转载请注明出处:
http://blog.csdn.net/horkychen
