準確的程序流控制

1 容易混淆的表達方式
先來看這樣兩段代碼：

在C標準中，條件語句需要的是布爾值，條件語句表達式的布爾值實際上是按照整型處理的，所以這兩段代碼在語法和邏輯上都沒有任何問題。第一段代碼判斷x是否等于y．如果相等，調用foo()函數(shù)；第二段代碼首先將y的值賦給x，然后判斷x是否為O，如果不為0，調用foo()函數(shù)。這兩段代碼只相差一個等號，卻使判斷條件大不相同，程序的執(zhí)行流程會出現(xiàn)很大差別。

相信讀者在寫程序的時候都碰到過將“==”這個判斷語句誤寫成賦值語句“=”的情況。那么面對這兩個語句時，如何能快速準確地判斷這是正確的還是程序員的失誤呢?當程序比較簡單的時候，很容易判斷，但當程序流程比較復雜的時候，可能花費大量時間還難以給出確定的答案，而這些地方極有可能是有錯誤的。

這樣的混淆，事實上是可以輕松避免的，MISRA-C提出了如下強制性的規(guī)則。
規(guī)則13．1：賦值表達式不能用在需要布爾值的地方。按照MISRA-C的標準，第二段代碼應該寫成：

這樣，當看到需要布爾值的地方出現(xiàn)了賦值表達式，就可以立即判斷這是一個錯誤。在這條規(guī)則下，如下的表達也是不允許的：

與這條規(guī)則類似，MISRA-C還提出了如下推薦的規(guī)則，來避免整型變量和布爾型的混淆。

規(guī)則13.2(推薦)；判斷一個值是否為0應該是顯式的，除非該操作數(shù)是一個布爾值。

這條規(guī)則禁止了如下的表達：

同樣，這段代碼在語法和邏輯上也沒有任何問題，編譯器也不會給出任何錯誤或者警告。在程序執(zhí)行中，當x等于l的時候，將b的值賦給a，然后將a加2，退出；當x等于2的時候，直接將a的值加2，接著退出。但這兒很可能是一段錯誤的代碼，程序員的本意有可能是x等于1時，將b的值賦給a，當x等于2時，直接將a的值加2。

為了避免這樣的混淆，MISRA-C提出了如下強制性的規(guī)則。

規(guī)則15.2：所有非空的switch 子句都應該以break語句結束。
按照這條規(guī)則，上面的程序應該寫成：

MISRA-C中還有一些防止程序流控制中出現(xiàn)混淆的規(guī)則。
規(guī)則13．5：for語句中的3個表達式只能和循環(huán)控制相關。第一個表達式只能為循環(huán)變量賦初值，第二個表達式只能進行循環(huán)條件的判斷，第三個表達式只能進行循環(huán)變量增(減)值。

規(guī)則13.6：for循環(huán)中，循環(huán)變量只能在for語句的第三個表達式中修改，不允許在循環(huán)體中修改。

規(guī)則13.7：布爾表達式的值必須是可以改變的。
例如，如下代碼是不允許的：

錯誤在于該條件判斷的結果始終為真。
規(guī)則14.1：不能存在無法執(zhí)行到的代碼。
規(guī)則14.2：非空語句必須要么產(chǎn)生副作用(side effect)；或者使程序流程改變。

例如，下面的代碼是不允許的：

…
x>=3；

…
錯誤在于x和3比較的結果被丟棄了。

規(guī)則14.3：一行中如果有空語句，那么該行只能有這條空語句，不能有別的語句，并且在這條空語句前不能有注釋，注釋必須在其后，用空格隔開。
例如，如下的代碼都是不允許的；

其中①的錯誤是除了空語句還有一條語句；②的錯誤是在空語句前有注釋；③的錯誤是空語句與注釋沒用空格隔開。

規(guī)則14.8：switch、while、d0．．．while和for語句的主體必須是復合語句(即用大括號包含)，即使該主體只包含一條語句。
例如，如下代碼是符合MISRA-C標準的：

規(guī)則14.9：if結構后面必須是一個復合語句(即用大括號包含)，else后面必須是一個復合語句(即用大括號包含)或者另一個if語句。
規(guī)則15.1：switch語句的主體必須是復合語句(即用大括號包含)。
規(guī)則15.2：所有非空的switch子句都應該用break語句結束。
規(guī)則15.3t switch的最后一個子句必須是default子句，如果default中沒有包含任何語句，那么應該有注釋來說明為什么沒有進行任何操作。
規(guī)則15.4：switch表達式不能是一個有效的布爾值。
例如，下面的代碼是不允許的：
switch(x==0)
{…)
規(guī)則15.5：switch語句必須至少包含一個case子句。

2 導致混亂的表達方式
在C語言中，有一些表達方式可以使程序的代碼量減少，但卻會使程序的結構化程度降低，流程控制變得混亂，可讀性大大降低?？聪旅嬉欢未a：
if(a>0x02)
{
loopl：b+=1；
if(c>0xA0){
goto loop3 ；

這段代碼讀起來很困難。實際編程時，程序員實現(xiàn)這段功能的代碼自然不會這樣寫，但是當程序流程復雜的時候，各種看起來能使編程工作變得輕松的表達，例如goto、continue等語句，卻會使程序流程變得混亂，可讀性降低，而隱藏其中的問題，很可能就無法發(fā)現(xiàn)了。

針對這種情況，MISRA-C給出了下面幾條強制規(guī)則。
規(guī)則14.4：不允許使用goto語句。
規(guī)則14.5：不允許使用continue語句。
規(guī)則14.6：循環(huán)體中最多只能出現(xiàn)一個break語句用于結束循環(huán)。
規(guī)則14.7：函數(shù)只能有一個出口，這個出口必須在函數(shù)末尾。
規(guī)則14.10：if...else if結構必須由一個else子句結束。
當if語句后面有一個或者多個else if語句時，最后的一個elseif必須有一個與之對應的else語句。如果只有一個if語句時，else不是必須的。

3 不確定的執(zhí)行結果
除了導致混淆和混亂的表達外，還有一些對浮點數(shù)的操作會導致不確定的結果。來看如下一段代碼：
f1oat32_t x，y ；
… ／*一些運算*／
if(x==y)
{…}
if的條件無法肯定什么情況為真。這是因為浮點數(shù)在計算機中無法用二進制精確表示，其運算總會存在舍入和切斷誤差，很多人看起來相等的結果，但計算機給出的兩個浮點數(shù)并不相等，所以上面代碼中if的主體語句什么情況執(zhí)行是不確定的。MISRA-C給出了兩條相關的規(guī)定來解決這一問題。

規(guī)則13.3：不允許對浮點數(shù)進行相等或者不相等的比較，即使是非直接的比較也是不允許的。
例如，如下非直接的比較也是不允許的：
float3Z_t x，y；
if(x=Y)
{…}
規(guī)則13.4：for循環(huán)的控制表達式不應包含浮點數(shù)類型。

3 小結
好的代碼，要安全可靠、有很好的可讀性和可維護性。在C語言中，一些表達方式，可能會稍微減少程序員編程的工作量，但卻會使程序的流程變得難以判斷，其中的錯誤可能就無法發(fā)現(xiàn)。

按照MISRA-C的標準來寫代碼，就可以避免程序流程產(chǎn)生混淆和混亂，排除其中的不確定因素，使程序真正按照程序員設想的工作，并使代碼更清晰易懂，真正實現(xiàn)安全可靠，并具有良好的可讀性和可維護性。