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

 這個(gè)函數(shù)參數(shù)應(yīng)該是const嗎?

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

程序構(gòu)建時(shí)沒(méi)有警告嗎?

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

代碼的圈復(fù)雜度是否小于10?

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

是否有標(biāo)題保護(hù)在場(chǎng)?

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

有任何阻塞功能嗎?

　　微控制器(MCU)的主要目的之一是能夠處理實(shí)時(shí)事件。MCU應(yīng)該能夠以一種非常確定的方式處理這些事件，這種方式可以被測(cè)量和證明。對(duì)于企業(yè)建設(shè)網(wǎng)站來(lái)講然而一個(gè)常見(jiàn)錯(cuò)誤是，一個(gè)驅(qū)動(dòng)程序或一些應(yīng)用程序代碼段被編寫(xiě)為進(jìn)入一個(gè)循環(huán)或調(diào)用一個(gè)延遲函數(shù)很長(zhǎng)一段時(shí)間。但是，循環(huán)或延遲會(huì)阻止任何其他代碼在處理器上運(yùn)行，這可能會(huì)損害確定性。

 是否受限于靜態(tài)的自由使用?

　品牌網(wǎng)站建設(shè),C 語(yǔ)言默認(rèn)變量的作用域?yàn)閑xtern，這個(gè)默認(rèn)值是隱式的，在模塊中聲明的不使用靜態(tài)變量的變量前面有一個(gè)不可見(jiàn)的大外部變量。擺脫那個(gè)不可見(jiàn)的外部的唯一方法是在聲明前面放置一個(gè)可見(jiàn)的靜態(tài)。這種做法的另一個(gè)好處是使變量在范圍內(nèi)成為局部變量，有助于數(shù)據(jù)隱藏和封裝。尋找隱式外部變量最常見(jiàn)的地方是模塊級(jí)變量聲明。

是否存在斷言和/或輸入/輸出檢查?

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

是否所有 if ... else if ... 條件都以 else 結(jié)尾?

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

是否使用了浮點(diǎn)數(shù)學(xué)?

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

 是否存在潛在的無(wú)限循環(huán)?

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

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

結(jié)論

　　許多工程師發(fā)現(xiàn)代碼審查非常無(wú)聊，但實(shí)際上很有趣，因?yàn)閳?zhí)行代碼審查可能是一個(gè)非常激動(dòng)人心的時(shí)刻。每個(gè)程序員對(duì)嵌入式軟件開(kāi)發(fā)和 C 語(yǔ)言都有自己獨(dú)特的觀點(diǎn)和見(jiàn)解，所以總有一些東西需要學(xué)習(xí)。然而，盡管嵌入式開(kāi)發(fā)人員正在實(shí)施許多見(jiàn)解和不同級(jí)別的檢查和平衡，但錯(cuò)誤仍然存在。這十個(gè)問(wèn)題解決了開(kāi)發(fā)嵌入式軟件時(shí)應(yīng)在每次代碼審查時(shí)檢查的常見(jiàn)錯(cuò)誤和誤解。