代码大全学习-22-常见的控制问题(General Control Issues)

    这一章类似于这一部分的一个总结。阐述了控制流程中常见的问题。比如布尔表达式,深层的嵌套等。
    布尔变量和布尔表达式是我们程序控制中不可或缺的组成部分。处理好它们,程序的控制流程会清晰明了,可读性,易用性都大大增加。具体说来,有下面这些值得注意:
    用true和false,不要用1和0.用if(a>b),不要用if((a>b)=true)。 
    简化复杂的布尔表达式。可以增加一个中间变量,用Demorgan定律简化,改成函数,用表等等。
    要舍得用括号。用括号是没有运行成本的,却可以很好的增加可读性,也避免优先级判断的错误。
    注意一些程序语言中对逻辑表达式的处理方法,比如C中几个&&连接的条件如果第一个是false后面的就不判断了之类的。最好是不要用这些特殊的方式,太隐藏了,会增加读程序人的理解时间。
    关于数字比大小的表达式可以按照从左到右从小到大写,视觉感更好。
    跟0的比较分清楚,是布尔值的用false,是数字的用0,是空指针的用NULL等。
    深层嵌套是一个我们经常会遇到的情况,然而超过3,4层的嵌套通常都让人难于理解。应该要想办法降低嵌套层数。当然这个也是要付出代价的,所以需要权衡。具体说来,基本上有这么一些方法:
    重复检查某些条件,这样可以把里层的条件往外面提一些。
    多层if可以改成if-else结构。
    多层if考虑能不能改成case。
    考虑内层的嵌套是否能改成函数。
    考虑面向对象的方法,继承,factory模式等。
    考虑增加一个状态变量。
    用异常处理。
    重新设计。
    作者的信条是除了标准的结构化编程,就是只用顺序,分支,循环三种结构,其他的任何方法都要小心。其原因就是这样可以降低复杂度,而复杂是软件的大敌。最后作者还提到了一个很简单的测量复杂度的方法,很有意思。
    这方法是Tom McCabe提出了,就是用决策点的数量来测量复杂度。数量越大,越复杂。计算方法是:从1开始数,没碰到这些关键字或者与它们等效的就加1:if,while,repeat,for,and,or。每个case也加一。按这个标准数下来,一个函数如果复杂度是5以内,基本上很好,6-10,可以考虑简化它,10以上,有些太复杂了,一定要考虑简化。当然这个标准不是那么完美,比如有些case语句包含很多个case,其实结构也还算简单。可以作为一个参考吧。
    其实还有很多其他的测量复杂度的方法,像用了多少数据啊,嵌套的层数啊,代码行数啊,变量的生存范围啊,输入输出的数量啊等等,都可以作为参考。
    最后同样附上Checklist: 
Checklist: General Control Issues
 Do expressions use True and False rather than 1 and 0?
 Are boolean values compared to True and False implicitly?
 Are numeric values compared to their test values explicitly?
 Have expressions been simplified by the addition of new boolean variables and the use of boolean functions and decision tables?
 Are boolean expressions stated positively?
 Do pairs of braces balance?
 Are braces used everywhere they're needed for clarity?
 Are logical expressions fully parenthesized?
 Have tests been written in number-line order?
 Do Java tests uses a.equals(b) style instead of a == b when appropriate?
 Are null statements obvious?
 Have nested statements been simplified by retesting part of the conditional, converting to if-then-else or case statements, moving nested code into its own routine, converting to a more object-oriented design, or improved in some other way?
 If a routine has a decision count of more than 10, is there a good reason for not redesigning it?

发布了63 篇原创文章 · 获赞 16 · 访问量 3万+

猜你喜欢

转载自blog.csdn.net/tyst08/article/details/7893933