多年來，開發(fā)人員在審查代碼時有一些常見的問題，無論公司的規(guī)模有多大，開發(fā)過程有多成熟，總會出現(xiàn)問題。為了幫助緩解這些常見問題，嵌入式開發(fā)人員在審查C代碼時可以提出一下10個問題，以幫助找到潛在的bug問題。

　　問題 1 – 程序構建時沒有警告嗎?

　　如果編譯不成功，就無法在目標上加載代碼。成功的編譯需要程序員努力消除任何語法錯誤，以使編譯器滿意并創(chuàng)建輸出文件。但是，編譯器可以構建一個沒有錯誤的應用程序，但仍然會發(fā)現(xiàn)其他異常，如隱式強制轉換，并將其報告為警告。因此，一個真正成功的程序編譯不僅應該零錯誤，還應該零警告。

　　問題2 – 有任何阻塞功能嗎?

　　微控制器(MCU)的主要目的之一是能夠處理實時事件。MCU應該能夠以一種非常確定的方式處理這些事件，這種方式可以被測量和證明。然而一個常見錯誤是，一個驅動程序或一些應用程序代碼段被編寫為進入一個循環(huán)或調用一個延遲函數(shù)很長一段時間。但是，循環(huán)或延遲會阻止任何其他代碼在處理器上運行，這可能會損害確定性。

　　問題3 – 是否存在潛在的無限循環(huán)?

　　哪個嵌入式開發(fā)人員會故意將無限循環(huán)放入他們的代碼中?(當然不包括那些在任務或應用程序的主循環(huán)中需要的代碼)。然而，網(wǎng)絡上和芯片供應商提供的許多示例代碼都表現(xiàn)出無限循環(huán)故障行為。例如，將數(shù)據(jù)寫入閃存或 EEPROM 的代碼通常會監(jiān)控硬件標志是否完成。示例代碼將在標志上創(chuàng)建一個 while 循環(huán)，以在繼續(xù)之前達到某個狀態(tài)。但是如果硬件出現(xiàn)故障并且標志永遠不會被設置，代碼就會陷入無限循環(huán)!

　　可以補救這種無限循環(huán)故障的一種方法是讓循環(huán)監(jiān)視系統(tǒng)滴答聲或限制循環(huán)在最終確定發(fā)生錯誤之前可以執(zhí)行的次數(shù)。這些補救措施允許在硬件發(fā)生故障時將錯誤處理內置到系統(tǒng)中。盡管普遍認為，硬件(和軟件)確實失敗了。

　　問題 4 – 這個函數(shù)參數(shù)應該是const嗎?

　　程序員往往不會盡可能多地使用const，尤其是在涉及函數(shù)參數(shù)時。將傳遞的函數(shù)參數(shù)聲明為const是防止該變量在函數(shù)中被意外修改的好方法。為什么讓未來的嵌入式開發(fā)人員意識到他們不應該修改該系統(tǒng)關鍵變量而應該只使用它呢?

　　問題 5 – 代碼的圈復雜度是否小于10?

　　監(jiān)控函數(shù)的圈復雜度度量是幫助限制函數(shù)變得復雜的好方法。該指標直接關系到需要在函數(shù)上執(zhí)行以測試每個分支的最小測試用例數(shù)量。不僅如此，該指標還真正說明了開發(fā)人員在編寫或修改函數(shù)時需要記住多少。由于大多數(shù)人一次只能跟蹤7到9件事，因此將圈復雜度保持在10以下是有助于降低錯誤率的好選擇。

　　問題 6 – extern 是否受限于靜態(tài)的自由使用?

　　C 語言默認變量的作用域為extern，這個默認值是隱式的，在模塊中聲明的不使用靜態(tài)變量的變量前面有一個不可見的大外部變量。擺脫那個不可見的外部的唯一方法是在聲明前面放置一個可見的靜態(tài)。這種做法的另一個好處是使變量在范圍內成為局部變量，有助于數(shù)據(jù)隱藏和封裝。尋找隱式外部變量最常見的地方是模塊級變量聲明。

　　問題 7 – 是否所有 if ... else if ... 條件都以 else 結尾?

　　在 switch 語句中使用默認情況應該是強制性的。如果不存在默認情況，靜態(tài)分析工具會報錯。嵌入式開發(fā)人員可以很容易地看到，如果條件保證在各種情況下使用 switch 語句，則可能會有一個意外或被忽略的情況，應該有一個默認的 end-all 情況。這也適用于 if ... else if ... 條件。如果要檢查兩個或多個條件，如果這些情況都不符合當前條件怎么辦?語句中的最后一個 else 就像 switch 語句中的默認情況一樣。

　　問題 8 – 是否存在斷言和/或輸入/輸出檢查?

　　嵌入式軟件開發(fā)人員應該在他們的代碼中添加斷言，以驗證他們對程序在某些點的行為的假設是否正確，應對入站和出站數(shù)據(jù)執(zhí)行邊界檢查。還記得那句老話“垃圾進，垃圾出”嗎?

　　問題 9 – 是否有標題保護在場?

　　標題保護是一個簡單的宏，可確保標題文件在翻譯單元中不包含多次。保護是防止雙重包含 #include 指令。不包括標題保護可能會導致一些非常奇怪的靜態(tài)分析行為，更重要的是，嵌入式開發(fā)人員使用保護可以防止多個定義錯誤。

　　問題 10 – 是否使用了浮點數(shù)學?

　　浮點數(shù)學的使用在嵌入式系統(tǒng)中可能是一個棘手的主題。資源受限的微控制器通常不包括浮點單元 (FPU)。這種缺失意味著處理器只有一種執(zhí)行浮點計算的方法：使用庫函數(shù)。用于浮點數(shù)學的庫函數(shù)通常緩慢且效率低下，它們不一定具有確定性行為，并且它們可能導致代碼規(guī)模膨脹。由于這些原因，開發(fā)人員應仔細考慮何時在微控制器中使用浮點。他們還應該執(zhí)行額外的測試，并應該考慮替代方法，例如查找表、縮放和定點數(shù)學。

　　結論

　　許多工程師發(fā)現(xiàn)代碼審查非常無聊，但實際上很有趣，因為執(zhí)行代碼審查可能是一個非常激動人心的時刻。每個程序員對嵌入式軟件開發(fā)和 C 語言都有自己獨特的觀點和見解，所以總有一些東西需要學習。然而，盡管嵌入式開發(fā)人員正在實施許多見解和不同級別的檢查和平衡，但錯誤仍然存在。這十個問題解決了開發(fā)嵌入式軟件時應在每次代碼審查時檢查的常見錯誤和誤解。