開發公司編碼標準對每個嵌入式開發人員絕對至關重要。編碼標準告訴開發人員他們需要做的許多事情和不做的事情，以便編寫清晰、可審查的軟件，以盡可能少的缺陷達到業務所需的質量水平。我們將在今天的文章中探討的七個標準。

　　1.范圍

　　定義公司標準將涵蓋的范圍非常重要，但經常被忽視。范圍告訴讀者該標準計劃涵蓋的內容以及它適用于誰!該標準僅適用于編寫微控制器應用程序的C開發人員，還是還包括編寫Linux應用程序或從事Linux內核工作的開發人員?該標準是否僅適用于開發的新代碼，還是該標準需要適用于遺留代碼?它是否也涵蓋第三方庫代碼?范圍為標準的其余部分以及應該繼續閱讀然后實施它的人奠定了基礎。

　　2.驗證

　　第二個是關于如何驗證標準的建議。有許多不同的方法可以驗證編碼標準。這些通常包括代碼審查和靜態代碼分析的組合。一個好的標準應該使用工具自動驗證，但這并不總是可能的。在建議開發人員驗證標準的時間進行評論很有用，例如，作為持續集成過程的一部分，開發人員是否應該在提交代碼之前驗證標準?還是只在發布時?這些是公司開發過程中經常涉及的問題，可能會發生變化。

　　3.外部參考

　　諸如C之類的嵌入式編程語言已經存在了半個世紀，沒有理由從頭開始制定標準!所以公司編碼標準的第三個應該是外部參考。例如，一家公司可能會參考MISRA-C或CERT-C等行業標準，然后列出嵌入式開發人員應該遵循哪些指令以及可以忽略哪些指令的期望。這些外部參考允許標準建立在行業已奠定的基礎上，并可以簡化制定公司標準所需的工作。

　　

　　4.C風格指南

　　幾乎每個開發人員都有自己的C代碼樣式。C風格指南部分可能是確保正在開發的代碼庫具有一致的外觀和感覺的最重要部分。這是列出重要指導方針的部分，例如：

　　間距

　　括號放置

　　允許的C關鍵字

　　避免使用的C關鍵字

　　評論塊的外觀

　　命名約定

　　ETC

　　如果開發人員都堅持C風格，那么幾乎不可能確定誰編寫了代碼，因為每個模塊看起來都應該一樣!

　　5.項目

　　我還發現，就項目的組織方式提出建議很有用。例如，本節可以討論以下領域：

　　軟件版本化

　　如何組織軟件層和模塊

　　推薦的硬件抽象層，例如 CMSIS

　　如何處理中斷服務程序、堆棧、堆和內存管理

　　集成第三方組件的建議。

　　ETC

　　包括這些細節還可以確保團隊工作的每個項目都是一致的，并且嵌入式開發人員可以輕松地從一個項目轉移到下一個項目。

　　

　　6.硬件/編譯器特定功能

　　開發人員還需要一些建議來連接硬件和使用編譯器。例如，本節可以概述是否可以使用#pragma，如果可以，允許使用哪些指令。(當然這是特定于編譯器的，因此編譯器的更改意味著標準的更改，因此外部參考文檔可能更有意義)。本節還可以演示與硬件寄存器和中斷接口的首選方法。例如，直接訪問注冊，通過指針機制訪問或使用指針配置結構。與硬件和編譯器相關的任何內容都將在此處記錄。

　　7.附錄

　　附錄可以包含大量對開發人員很重要但不一定屬于編碼標準的其余部分的信息。例如，一個團隊可能包含一個定義“術語表”的附錄，以便公司的任何新開發人員都可以學習公司內部使用的術語，但不一定是行業公認的術語。跟蹤此類信息可以確保編碼人員所需的一切都在一個地方，這樣他們就無需在需要參考時浪費時間尋找它。

　　結論

　　公司編碼標準是每個嵌入式開發團隊都應該擁有的重要文件，這些文檔為項目的實施奠定了基礎，并且可以極大地影響代碼庫的質量。如果你有一個編碼標準，你應該至少每年審查一次，以確保它的指導仍然有意義，如果你沒有編碼標準，則可以首先使用此文章建議的部分作為標準文檔的大綱，每月更新一次，直到你擁有完整記錄的編碼標準。