隨著技術的不斷進步，客戶期望越來越高，嵌入式設備變得越來越智能，對應的嵌入式系統和軟件也變得越來越復雜，同時產品的開發周期變得越來越短。如何在短時間內開發出高質量的軟件對產品的成功起著決定性的作用。提高代碼質量是一個系統工程，本文主要介紹開發人員如何在日常開發過程中提高代碼質量。

01

什么是代碼質量？

代碼質量一般用于衡量代碼的“好”和“爛”：“好”代碼表示代碼質量高，“爛”代碼表示代碼質量低。雖然目前代碼質量沒有一個單一客觀的定義，但是代碼質量一般可以通過一些指標來衡量：

可讀性(Readability)：“好”代碼應該易于閱讀和理解。

可靠性(Reliability)：“好”代碼應該是可靠的(Bug越少，代碼質量越高)。

可測試性(Testability)：“好”代碼應該易于測試。

可重用性(Reusability)：“好”代碼應該易于在不同項目里面重用。

可維護性(Maintainability)：“好”代碼應該易于修改和維護。

可擴展性(Extensibility)：“好”代碼應該易于擴展。

可移植性(Portability)：“好”代碼應該易于在不同的平臺上移植。

02

如何提高代碼質量？

提高代碼質量不是一項一次性任務，而是一項需要長期堅持的實踐。下面是目前常用的一些提高代碼質量的實踐：

遵循編碼標準：編碼標準是前輩總結的一些編碼最佳實踐和經驗教訓。編碼標準一般分為公司內部編碼標準(比如代碼風格和命名規則等)和行業編碼標準(比如MISRA， CERT和CWE等)。

靜態代碼分析：靜態代碼分析可以幫助檢查代碼是否遵循相關編碼標準。

單元測試：單元測試主要是功能測試，可以幫助測試代碼是否符合對應的設計，確保代碼功能的正確性。

代碼審查：代碼審查可以加強開發者之間的協作，幫助檢查代碼中潛在的邏輯問題。

使用版本控制：使用版本控制可以管理代碼變更歷史，同時方便團隊協作。

CI/CD：CI/CD可以實現自動化構建、靜態代碼分析和單元測試。

03

為什么需要在日常開發過程中提高代碼質量？

下面是Capers Jones 的著作“Applied Software Measurement: Global Analysis of Productivity and Quality”里面關于Bug引入、檢測和修復成本的一張圖：

絕大部分Bug是在日常開發編碼階段引入的。

Bug發現的越早，越容易修復，修復成本越低；反之Bug發現的越晚，越難修復，修復成本越高。

在日常開發編碼階段過程中提高代碼質量，可以盡早發現代碼中的Bug，盡快修復代碼中的Bug，大大降低修復Bug的成本。

04

如何在日常開發過程中提高代碼質量？

前面介紹了提高代碼質量的一些通用實踐，下面具體介紹開發人員如何在日常開發過程中提高代碼質量。

構建0 Error和0 Warning

在構建的時候，開發人員會做到0 Error (因為Error會導致構建失敗)。但是很多時候沒有做到0 Warning (因為Warning不會導致構建失敗)。但是Waring有可能是潛在的隱藏的Bug。

下面是一個經典的編譯器Warning：提示應該使用比較運算符==而不是賦值符=：

修改之后重新構建：0 Error和0 Warning:

靜態代碼分析

構建0 Error和0 Warning之后，建議先做靜態代碼分析，因為靜態代碼分析不需要運行代碼，分析起來比較方便快捷，而且靜態代碼分析能檢測出一些常見的代碼錯誤。

在IAR Embedded Workbench當中，只需要先勾選對應的C-STAT靜態代碼檢查規則：

就可以使用C-STAT對整個工程進行靜態代碼分析：

也可以使用C-STAT對單個文件進行靜態代碼分析：

分析完成后，對應C-STAT Messages窗口會顯示對應檢查結果，雙擊對應信息可以定位到源代碼位置：

如果不太熟悉對應檢查規則，可以按F1，會彈出對應幫助文檔(包含對應檢查規則的描述，對應編碼標準以及違反和遵循對應規則的代碼示例等)來幫助快速定位和解決問題：

根據幫助文檔中的信息，推測需要將代碼里面的4u改成(int32_t) 4。修改代碼之后重新進行靜態代碼分析，之前的違反修復了：

使用IAR C-STAT可以非常方便地進行靜態代碼分析并且迅速得到反饋，以確保代碼符合相應的編碼標準。

單元測試

在靜態代碼分析之后，建議做單元測試。因為靜態代碼分析只能檢查代碼是否遵循相關編碼標準，代碼的功能測試還需要單元測試。IAR本身沒有提供單元測試工具，IAR有很多提供單元測試工具的合作伙伴。同時IAR里面的C-RUN動態代碼分析可以幫助在單元測試時發現一些潛在的問題。

在IAR Embedded Workbench當中，只需要勾選對應的C-RUN動態代碼檢查規則：

重新構建，編譯器會在有可能出現違反的地方自動插入對應的測試代碼。

在運行的時候C-RUN會檢測是否有對應的違反，比如下面C-RUN Messages提示訪問越界：

分析發現對應數組的大小是4，但是錯誤地引用了[4]( [4]是數組的第5個元素)，導致訪問越界。修改代碼之后重新測試OK (C-RUN Messages窗口沒有對應違反)：

代碼審查 在單元測試完成之后，建議邀請同伴做代碼審查(為了提高代碼審查的效率，建議在構建、靜態代碼分析和單元測試完成之后再做代碼審查)。

CI/CD

在代碼審查完成之后，建議上傳代碼到服務器進行自動化工作流。

IAR提供了對應的自動化工具IAR Build Tools可以通過命令行的方式進行自動化構建、靜態代碼分析和下載調試(用于單元測試)：

05

總結

在與用戶的交流中，我們欣喜地發現越來越多的公司和開發人員意識到代碼質量的重要性，但同時也發現了一些問題：

有些公司居然沒有對代碼進行靜態代碼分析、單元測試和代碼審查，代碼的正確性和質量完全依靠最后的產品測試。

有些公司購買了非常好的靜態代碼分析和單元測試工具，但是遺憾的是這些工具并沒有被開發人員在日常開發過程中充分使用，而是等到發布軟件版本之后才對整個工程進行靜態代碼分析和單元測試。

有些公司還沒有部署自動化工作流(開發人員的時間非常寶貴，要盡量對代碼進行自動化構建、靜態代碼分析和單元測試，這樣開發人員就可以盡快收到反饋，提高代碼質量的同時也提升研發效率)。

本文以IAR Embedded Workbench和IAR Build Tools(包含C-STAT靜態代碼分析和C-RUN動態代碼分析)為例介紹了開發人員如何在日常開發過程中提高代碼質量。

需要注意的是，文中的IAR Embedded Workbench和IAR Build Tools(包含C-STAT靜態代碼分析和C-RUN動態代碼分析)只是工具示例，文中的策略也適用于其它工具。

選擇對應的工具很重要，但是更重要的是：開發人員需要在日常開發過程中充分利用好對應的工具來提高代碼質量。因為絕大部分Bug是在日常開發編碼階段引入的，Bug發現的越早，越容易修復，修復成本越低；反之Bug發現的越晚，越難修復，修復成本越高。

更多關于IAR Embedded Workbench和Build Tools(包含C-STAT靜態代碼分析和C-RUN動態代碼分析)的信息，可以參考：

https://www.iar.com/zh/products/architectures/arm/iar-embedded-workbench-for-arm/

https://www.iar.com/zh/products/architectures/arm/iar-build-tools-for-arm/

https://www.iar.com/zh/products/c-stat

https://www.iar.com/zh/products/c-run