由于嵌入式系統(tǒng)行業(yè)的快速發(fā)展，嵌入式設(shè)備的代碼質(zhì)量成為首要關(guān)注的問題之一?？紤]到嵌入式系統(tǒng)開發(fā)的特殊性（調(diào)試困難、出錯成本高等），開發(fā)人員需要使用專門的工具來提升自己的代碼質(zhì)量。

靜態(tài)代碼分析器就是這些工具之一。本文描述了靜態(tài)分析以及它如何在嵌入式系統(tǒng)中受益。

靜態(tài)代碼分析

首先，讓我們弄清楚靜態(tài)代碼分析器是什么以及它們可以執(zhí)行哪些功能。

靜態(tài)代碼分析器是分析程序而不實際執(zhí)行它的軟件。靜態(tài)分析工具比編譯器對源代碼進行更深入的檢查。通常，編譯器只發(fā)現(xiàn)語法錯誤。

靜態(tài)分析工具的工作原理：

分析器的輸入數(shù)據(jù)是源代碼（最好是可編譯的）

分析器將源代碼轉(zhuǎn)換為特殊模型以供進一步分析（AST、語義模型等）；

分析器通過對模型應(yīng)用一組診斷規(guī)則來搜索缺陷。診斷規(guī)則基于各種方法；

分析儀以方便您的格式保存所有發(fā)出的警告；

開發(fā)人員只需要研究報告并修復(fù)所有缺陷；

利潤！

靜態(tài)分析儀可以執(zhí)行廣泛的任務(wù)。讓我們介紹分析器最常見的任務(wù)：

程序代碼中的錯誤檢測。在這種情況下，靜態(tài)分析極大地補充了代碼審查。它允許您在您和您的同事開始繁瑣的代碼審查之前發(fā)現(xiàn)并解決許多問題；

廣義上的代碼質(zhì)量增強。代碼質(zhì)量可以包括可讀性、可維護性、代碼復(fù)雜性、內(nèi)聚程度以及可以直接或間接影響錯誤數(shù)量的其他方面。因此，靜態(tài)分析器有助于遵循編碼標準（在公司內(nèi)接受并普遍接受）；

代碼分析作為 CI/CD 中質(zhì)量門機制的一部分。分析器不僅可以警告代碼中的潛在錯誤，還可以作為一種保護機制。如果代碼質(zhì)量水平不符合規(guī)定的要求，他們就會停止持續(xù)交付。如果檢測到錯誤或不符合標準的代碼片段，此類代碼分析器會擴展編譯器行為并阻止構(gòu)建；

項目指標的收集、統(tǒng)計數(shù)據(jù)的收集、反映項目“總體健康狀況”的圖形和圖表結(jié)構(gòu)。

實施效益

靜態(tài)分析器已被證明對嵌入式軟件非常有用。讓我們看看靜態(tài)分析最明顯的積極方面。

首先，靜態(tài)分析的使用減少了昂貴的（如果不是不可能的話）已經(jīng)發(fā)布的設(shè)備“閃爍”的可能性。

嵌入式系統(tǒng)軟件中的錯誤非常麻煩。問題是一旦開始大規(guī)模生產(chǎn)，這些錯誤就不可能或幾乎不可能糾正。假設(shè)一家公司已經(jīng)生產(chǎn)了數(shù)千臺洗衣機并將其交付給商店。但是，結(jié)果機器在某種模式下無法正常工作。公司應(yīng)該怎么做？一般來說，這個問題是修辭性的，有兩種實際選擇：

順其自然，在各個網(wǎng)站上收到負面的客戶反饋，破壞聲譽。當然，公司可以發(fā)布并發(fā)送手動添加說“不要這樣做”。然而，這是一個“弱”的選擇；

退出銷售機器并開始更新固件。這是一個昂貴的選擇。

發(fā)布多少設(shè)備并不重要。修復(fù)錯誤可能有問題，甚至為時已晚?；鸺龎嫐Аe誤被發(fā)現(xiàn)，但為時已晚。患者死亡——錯誤被檢測到，但它不會讓人們回來。導(dǎo)彈防御系統(tǒng)的目標精度損失- 檢測到錯誤，但損壞已經(jīng)造成。汽車休息不起作用- 檢測到錯誤，但這無助于車禍受害者。程序錯誤的代價是可怕的，不是嗎？

結(jié)論很簡單：嵌入式設(shè)備的代碼應(yīng)該盡可能徹底地測試。特別是如果錯誤可能導(dǎo)致人員傷亡或巨大的經(jīng)濟損失。

靜態(tài)代碼分析是檢測錯誤的過程，但它不保證會發(fā)現(xiàn)代碼中的所有錯誤。但是，開發(fā)人員應(yīng)該利用任何機會額外檢查代碼的正確性。靜態(tài)分析器可以指出即使在多次代碼審查之后仍然存在的各種錯誤。

如果靜態(tài)分析可以幫助減少設(shè)備代碼中的錯誤數(shù)量，那就太棒了。也許這些特殊錯誤的發(fā)現(xiàn)將防止生命損失?；蛘撸苍S這些公司不會浪費很多錢，也不會因為客戶投訴而失去良好的聲譽。

其次，靜態(tài)代碼分析器顯著降低了軟件測試和調(diào)試過程的成本。

靜態(tài)分析允許您在編碼期間或夜間構(gòu)建期間發(fā)現(xiàn)錯誤。結(jié)果，大多數(shù)錯誤的搜索和修復(fù)可以便宜得多。

可能每個開發(fā)人員都嘗試過“刷新”設(shè)備，但沒有成功。例如，在此過程中，設(shè)備沒有設(shè)置正確的電壓或完全燒壞。發(fā)生了什么，您在哪里尋找問題？畢竟，不僅僅是軟件錯誤可能是問題的根源。也可能是硬件本身的錯誤或質(zhì)量差的布局。因此，發(fā)現(xiàn)錯誤的過程可能需要很長時間。

最悲傷的場景：

開發(fā)人員 100% 確定他編寫的代碼是正確的；

電路工程師和其他負責(zé)硬件的同事參與了該項目；

尋找問題的過程緩慢而費力；

開發(fā)人員再次查看代碼并突然發(fā)現(xiàn) - 一個錯字；

超級低效浪費隊友的精力和時間；

這很尷尬和不愉快。

由于以下原因，可能會彈出此類錯誤。在正在進行的項目中，開發(fā)人員使用了他的舊做法，他需要至少適應(yīng)項目。例如，他可以編寫以下代碼片段：

uchar Arr［3］;

。..。

for （uchar idx = 0; idx ！= 4; idx++）

avg += Arr［idx］;

avg /= 3;

這個錯誤的背景如下。開發(fā)人員以他之前的開發(fā)為基礎(chǔ)，代碼主要是使用復(fù)制粘貼方法編寫的。他沒注意，忘了把4換成3在一行。結(jié)果，他在訪問位于數(shù)組邊界之外的索引時出現(xiàn)了未定義的行為。這樣的代碼可能是陰險的。程序在調(diào)試過程中可以正常工作。但是，在實際情況下，當客戶端多次運行它時，它可能會崩潰。如果靜態(tài)分析器發(fā)現(xiàn)這樣的錯誤，那就太好了。

因此，為避免調(diào)試過程曲折而費力，在刷機之前盡可能多地檢測出缺陷位置非常重要。

第三，靜態(tài)分析的使用保證了沒有太多經(jīng)驗的開發(fā)人員。

程序錯誤可以形象地分為兩種類型。開發(fā)人員知道第一種類型的錯誤。由于疏忽，這些錯誤意外地出現(xiàn)在代碼中。第二種錯誤出現(xiàn)在開發(fā)人員根本不知道不可能以這種方式編寫代碼的情況下。換句話說，他們可以隨心所欲地查看此類代碼，但仍然不會發(fā)現(xiàn)錯誤。

靜態(tài)分析器包含有關(guān)各種代碼模式的知識庫。在某些情況下，這些模式會導(dǎo)致錯誤。因此，他們可以指出開發(fā)人員自己不會發(fā)現(xiàn)的錯誤。一個例子是使用 32 位 time_t 類型，這可能會導(dǎo)致設(shè)備在2038之后無法正常工作。

另一個例子是程序的未定義行為，這是由于不當使用移位運算符《《/》》而發(fā)生的。這些運算符在微控制器的代碼中被廣泛使用。不幸的是，開發(fā)人員經(jīng)常非常粗心地使用這些運算符。這使得程序不可靠并且依賴于編譯器的特定版本和設(shè)置。同時，程序可以運行，但這不是因為它的代碼寫得對，而是因為開發(fā)者很幸運。

使用靜態(tài)分析器，開發(fā)人員可以對沖許多此類不愉快的情況。此外，您可以使用分析器來控制整體代碼質(zhì)量。當項目的團隊正在成長或變化時，這一點很重要。換句話說，分析器有助于跟蹤初學(xué)者是否開始編寫糟糕的代碼。

第四，現(xiàn)代靜態(tài)分析器不僅能發(fā)現(xiàn)代碼錯誤和漏洞，還支持嵌入式系統(tǒng)的編碼標準。這些標準提高了程序的安全性、可移植性和可靠性水平。

C 和 C++ 被稱為嵌入式系統(tǒng)的流行編程語言。MISRA C、MISRA C++ 和 AUTOSAR C++ 等標準是為這些語言開發(fā)的。每個標準都有相當多的規(guī)則和建議（MISRA C：143，MISRA C++：228，AUTOSAR C++：超過 350）。在沒有靜態(tài)代碼分析器的情況下編碼時，根本不可能遵守這么多的規(guī)則和建議。這些規(guī)則是開發(fā)人員需要避免的編碼模式，從而減少出錯的可能性。目前，所有主要的靜態(tài)分析參與者（Coverity、Klockwork、PVS-Studio，。..）都在努力盡可能地增加標準的覆蓋范圍。

編碼標準

MISRA 的歷史始于很久以前?；氐?90 年代初，“安全 IT”英國政府計劃為各種與電子系統(tǒng)安全相關(guān)的項目提供資金。MISRA（汽車工業(yè)軟件可靠性協(xié)會）項目本身的成立是為了創(chuàng)建用于開發(fā)陸地車輛微控制器軟件的指南 - 主要是汽車。

MISRA（作為一個組織）是一個由來自各種汽車和飛機行業(yè)的利益相關(guān)者組成的社區(qū)。

賓利汽車；

福特汽車公司；

捷豹路虎；

德爾福柴油系統(tǒng)；

堀場米拉；

千變?nèi)f化電氣；

偉世通工程服務(wù)；

利茲大學(xué)；

英國里卡多；

采埃孚天合。

非常強大的市場參與者，不是嗎？毫不奇怪，他們的第一個與語言相關(guān)的標準 MISRA C 在關(guān)鍵嵌入式系統(tǒng)的開發(fā)人員中獲得了廣泛的認可。不久之后，出現(xiàn)了 MISRA C++。逐漸地，標準的版本已經(jīng)更新和修訂，以涵蓋語言的新功能。目前，當前版本是 MISRA C： 2012 和 MISRA C++： 2008。

MISRA 最顯著的特點是其對細節(jié)的難以置信的關(guān)注和在確保安全和安保方面的極度細致。作者不僅將所有 C 和 C++ 缺陷集中在一個地方（例如 CERT 的作者）。他們還仔細制定了這些語言的國際標準，并寫出了所有可能出錯的方法。之后，他們添加了關(guān)于代碼可讀性的規(guī)則和建議。畢竟，在簡單易讀的代碼中更難出錯，在 Code-Review 期間更容易發(fā)現(xiàn)錯誤。

通常，第一次遇到 MISRA 的人會覺得該標準的目的是“禁止這個和禁止那個”。事實上，確實如此，但只是部分如此。

該標準確實有許多禁止某些行為的規(guī)則。但是，這并不是要全面禁止，而是要列出所有可能導(dǎo)致安全漏洞的方式。對于大多數(shù)規(guī)則，您自己選擇是否需要遵守它們。讓我更詳細地解釋一下。

MISRA C 規(guī)則分為三個主要類別：強制、必需和建議。在任何情況下都不得違反強制性規(guī)則。例如，本節(jié)包括規(guī)則：“不要使用未啟動變量的值”。所需的規(guī)則不那么嚴格。它們允許偏差的可能性。但是開發(fā)人員需要以書面形式證明這些偏差的合理性并詳細記錄它們。其余規(guī)則屬于咨詢類別——它們是非強制性的。

MISRA C++ 有點不同：沒有 Mandatory 類別，大部分規(guī)則屬于Required 類別。因此，事實上，您有權(quán)違反任何規(guī)則——只是不要忘記記錄偏差。還有文檔類別。它包括與一般實踐相關(guān)的強制性規(guī)則（不允許有偏差），例如“必須記錄匯編程序的每次使用”或“包含的庫必須符合 MISRA C++”。

該標準既包含對問題問題的描述，也包含在承擔(dān)某項任務(wù)之前必須了解的提示：如何根據(jù) MISRA 設(shè)置開發(fā)流程；如何使用靜態(tài)分析器檢查代碼的合規(guī)性；一個人必須維護哪些文件，如何填寫它們等等。

目前，MISRA 不斷發(fā)展。例如，MISRA 在 2019 年初發(fā)布了《MISRA C:2012 第三版（第一次修訂）》。這是 MISRA C:2012 版更新和擴展了新規(guī)則。同時，即將發(fā)布的《MISRA C： 2012 Amendment 2 – C11 Core”公布，這是 2012 年的修訂標準。

MISRA C++ 也不會停滯不前。如您所知，MISRA C++ 的最后一個標準可以追溯到 2008 年，因此它所涵蓋的語言的最新版本是 C++03。正因為如此，還有一個類似于MISRA的標準，它的名字叫AUTOSAR C++。它最初旨在作為 MISRA C++ 的延續(xù)，并旨在涵蓋該語言的更高版本。與其策劃者不同，AUTOSAR C++ 每年更新兩次，目前支持 C++14。新的 C++17 和 C++20 更新尚未到來。

結(jié)論

在本文中，我想說明使用靜態(tài)分析器對任何嵌入式項目都絕對有用。使用靜態(tài)分析將幫助您：

減少查找和修復(fù)錯誤所需的時間；

減少嚴重錯誤的可能性；

減少對固件更新的需求；

監(jiān)控整體代碼質(zhì)量；

監(jiān)控新團隊成員的表現(xiàn)；

嚴格遵守一定的軟件開發(fā)標準；

監(jiān)控第三方模塊/庫的代碼質(zhì)量。

審核編輯：郭婷