准确的程序流控制

1 容易混淆的表达方式
    先来看这样两段代码：

   
    在C标准中，条件语句需要的是布尔值，条件语句表达式的布尔值实际上是按照整型处理的，所以这两段代码在语法和逻辑上都没有任何问题。第一段代码判断x是否等于y．如果相等，调用foo()函数；第二段代码首先将y的值赋给x，然后判断x是否为O，如果不为0，调用foo()函数。这两段代码只相差一个等号，却使判断条件大不相同，程序的执行流程会出现很大差别。

    相信读者在写程序的时候都碰到过将“==”这个判断语句误写成赋值语句“=”的情况。那么面对这两个语句时，如何能快速准确地判断这是正确的还是程序员的失误呢?当程序比较简单的时候，很容易判断，但当程序流程比较复杂的时候，可能花费大量时间还难以给出确定的答案，而这些地方极有可能是有错误的。

    这样的混淆，事实上是可以轻松避免的，MISRA-C提出了如下强制性的规则。
    规则13．1：赋值表达式不能用在需要布尔值的地方。按照MISRA-C的标准，第二段代码应该写成：

   
    这样，当看到需要布尔值的地方出现了赋值表达式，就可以立即判断这是一个错误。在这条规则下，如下的表达也是不允许的：

   
    与这条规则类似，MISRA-C还提出了如下推荐的规则，来避免整型变量和布尔型的混淆。

    规则13.2(推荐)；判断一个值是否为0应该是显式的，除非该操作数是一个布尔值。

    这条规则禁止了如下的表达：

   
    同样，这段代码在语法和逻辑上也没有任何问题，编译器也不会给出任何错误或者警告。在程序执行中，当x等于l的时候，将b的值赋给a，然后将a加2，退出；当x等于2的时候，直接将a的值加2，接着退出。但这儿很可能是一段错误的代码，程序员的本意有可能是x等于1时，将b的值赋给a，当x等于2时，直接将a的值加2。

    为了避免这样的混淆，MISRA-C提出了如下强制性的规则。

    规则15.2：所有非空的switch 子句都应该以break语句结束。
    按照这条规则，上面的程序应该写成：

   
    MISRA-C中还有一些防止程序流控制中出现混淆的规则。
    规则13．5：for语句中的3个表达式只能和循环控制相关。第一个表达式只能为循环变量赋初值，第二个表达式只能进行循环条件的判断，第三个表达式只能进行循环变量增(减)值。

    规则13.6：for循环中，循环变量只能在for语句的第三个表达式中修改，不允许在循环体中修改。

    规则13.7：布尔表达式的值必须是可以改变的。
    例如，如下代码是不允许的：

   
    错误在于该条件判断的结果始终为真。
    规则14.1：不能存在无法执行到的代码。
    规则14.2：非空语句必须要么产生副作用(side effect)；或者使程序流程改变。

    例如，下面的代码是不允许的：

    …
    x>=3；

    …
    错误在于x和3比较的结果被丢弃了。

    规则14.3：一行中如果有空语句，那么该行只能有这条空语句，不能有别的语句，并且在这条空语句前不能有注释，注释必须在其后，用空格隔开。
    例如，如下的代码都是不允许的；

   
    其中①的错误是除了空语句还有一条语句；②的错误是在空语句前有注释；③的错误是空语句与注释没用空格隔开。

    规则14.8：switch、while、d0．．．while和for语句的主体必须是复合语句(即用大括号包含)，即使该主体只包含一条语句。
    例如，如下代码是符合MISRA-C标准的：

   
    规则14.9：if结构后面必须是一个复合语句(即用大括号包含)，else后面必须是一个复合语句(即用大括号包含)或者另一个if语句。
    规则15.1：switch语句的主体必须是复合语句(即用大括号包含)。
    规则15.2：所有非空的switch子句都应该用break语句结束。
    规则15.3t switch的最后一个子句必须是default子句，如果default中没有包含任何语句，那么应该有注释来说明为什么没有进行任何操作。
    规则15.4：switch表达式不能是一个有效的布尔值。
    例如，下面的代码是不允许的：
    switch(x==0)
    {…)
    规则15.5：switch语句必须至少包含一个case子句。

2 导致混乱的表达方式
    在C语言中，有一些表达方式可以使程序的代码量减少，但却会使程序的结构化程度降低，流程控制变得混乱，可读性大大降低。看下面一段代码：
    if(a>0x02)
    {
    loopl：b+=1；
    if(c>0xA0){
    goto loop3 ；

   
    这段代码读起来很困难。实际编程时，程序员实现这段功能的代码自然不会这样写，但是当程序流程复杂的时候，各种看起来能使编程工作变得轻松的表达，例如goto、continue等语句，却会使程序流程变得混乱，可读性降低，而隐藏其中的问题，很可能就无法发现了。

    针对这种情况，MISRA-C给出了下面几条强制规则。
    规则14.4：不允许使用goto语句。
    规则14.5：不允许使用continue语句。
    规则14.6：循环体中最多只能出现一个break语句用于结束循环。
    规则14.7：函数只能有一个出口，这个出口必须在函数末尾。
    规则14.10：if...else if结构必须由一个else子句结束。
    当if语句后面有一个或者多个else if语句时，最后的一个elseif必须有一个与之对应的else语句。如果只有一个if语句时，else不是必须的。

3 不确定的执行结果
    除了导致混淆和混乱的表达外，还有一些对浮点数的操作会导致不确定的结果。来看如下一段代码：
    f1oat32_t x，y ；
    … ／*一些运算*／
    if(x==y)
    {…}
    if的条件无法肯定什么情况为真。这是因为浮点数在计算机中无法用二进制精确表示，其运算总会存在舍入和切断误差，很多人看起来相等的结果，但计算机给出的两个浮点数并不相等，所以上面代码中if的主体语句什么情况执行是不确定的。MISRA-C给出了两条相关的规定来解决这一问题。

    规则13.3：不允许对浮点数进行相等或者不相等的比较，即使是非直接的比较也是不允许的。
    例如，如下非直接的比较也是不允许的：
    float3Z_t x，y；
    if(x<=Y)
    {…}
    规则13.4：for循环的控制表达式不应包含浮点数类型。

3 小结
    好的代码，要安全可靠、有很好的可读性和可维护性。在C语言中，一些表达方式，可能会稍微减少程序员编程的工作量，但却会使程序的流程变得难以判断，其中的错误可能就无法发现。

    按照MISRA-C的标准来写代码，就可以避免程序流程产生混淆和混乱，排除其中的不确定因素，使程序真正按照程序员设想的工作，并使代码更清晰易懂，真正实现安全可靠，并具有良好的可读性和可维护性。