为什么程序要了解思维的障碍,并要练习有意识的加以克服?这里举一个实际发生的问题。
写代码像写作一样,有时思如泉涌,顺着思路就把一段代码写得有模有样。
下面是一个状态码检查的例子(这种写法本身并不严谨,但这里要讨论是一个更为严重的问题.):
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