一、簡介

代碼編寫規則應該在建立一個工程項目之前，應該貫穿整個項目的始終，以保證代碼的一致性。采用標準的代碼編寫慣例，可以大大簡化項目的維護負擔。采用一種好的風格，以達到以下目的：可移植性、連貫、整潔、易于維護、易于理解、簡潔。

---

二、基本原則

制定標準的基本目的是加強代碼的可維護性。也就是說代碼必須易于閱讀、易于理解、易于測試、易于移植。保持代碼的簡單清晰，不要在語言中使用晦澀難懂的表達，直接表明你的思想。保持一致性，盡可能使用同樣的規則，避免使用復雜語句，一個語句若有太多的決策點將會使代碼難于理解，尤其是對于測試。一旦修改已存在的代碼，就要隨時更新相關文檔。

---

三、排版

1. 程序塊縮進

程序塊要采用縮進風格編寫，縮進的空格數為4個。在編碼之前對相關IDE進行設置，如若沒有縮進設置，需要在編寫完代碼后使用相關工具格式化代碼。

2. 代碼群落加空格

相對獨立的程序塊之間、變量說明之后必須加空行。

不符合規范——

void *th_func(void *arg) {int specific = (int)(int *)arg;for (int i = 0; i <= specific; i++){printf(“%lx run %d mn”, pthread_self(), i);int time = (int)(drand48() * 10000);usleep(time);}return (void *)0; }

符合規范——

void *th_func(void *arg) {int specific = (int)(int *)arg;for (int i = 0; i <= specific; i++){printf(“%lx run %d mn”, pthread_self(), i);int time = (int)(drand48() * 10000);usleep(time);}return (void *)0; }

3. 一行不要超過80列

較長的語句（>80字符）要分成多行書寫，長表達式要在低優先級操作符處劃分新行，操作符放新行之首，劃分出的新行要進行適當的縮進，使排版整齊，語句可讀。
循環、判斷等語句中若有較長的表達式或語句，則要進行適當的劃分，長表達式要在低優先級操作符處分新行，操作符放在新行之首。
若函數或過程中的參數較長，則要進行適當的劃分。
不允許把多個短語句寫在一行中，即一行只寫一條語句。

4. 流程控制語句必須用大括號包含起來

if、for、do、while、case、switch、default等語句自占一行，且if、for、do、while等語句的執行語句無論多少行都要加大括號{}。

5. 操作符

在兩個以上的關鍵字、變量、常量進行對等操作時。它們之間的操作符之前、之后或者前后都要加空格；進行非對等操作時，如果關系密切的立即操作符，后不應加空格。

逗號只在后面加空格——

int a, b, c;

比較操作符、賦值操作符、算術操作符、邏輯操作符、位域操作符等雙目操作符前后都要加空格——

if (a == n) a = b + c; a *= 2; a = b ^ 2; pid = p->pid;

單目操作符前后不加空格——

*p = &q; flag = !isEmpty; ++i; j++;

if、for、while、switch等與后面的括號間應加空格，使if等關鍵字更為突出、明顯——

if (a >= b && c > d)

6. 函數排版

相似的模板、相似的代碼順序、相似的函數排版靠近。

7. 頭文件包含次序

頭文件include從抽象到具體，次序：C標準庫→C++標準庫→OS相關→第三方庫→工程頭文件。

---

四、注釋

注釋的原則是有助于對程序的閱讀理解以及提供二次開發所需文檔，注釋標準參考Doxygen代碼注釋規范。遵循原則為，說明性文件、函數接口必須充分注釋說明。全局變量需要說明功能及取值范圍，需要自行處理資料函數需要加上使用警告信息。

不要使用注釋來屏蔽代碼。

關于函數和局部變量的注釋，當代碼已經可自注釋，不用添加多余的注釋。

---

五、標識符命名

標識符的命名要清晰明了，有明確含義，同時使用完整的單詞或大家基本可以理解的縮寫，避免使人產生誤解。命名中若有使用特殊約定或縮寫，則要有注釋說明。整個工程自始自終的命名風格保持一致，不可來回變化。

1. 對于變量名，禁止取單個字符（如i、j、k……），建議除了要有具體含義外，還能表明其變量類型、數據類型等，但i、j、k作局部循環變量是允許的。

建議命名如下：

<數據類型>[模塊名]<變量作用域><變量數據類型><變量類型><變量名>

/* 全局變量 */ int comm_giv_width; char *comm_gcp_width; const int comm_gic_max;/* 局部變量 */ int liv_width; char *lcp_width; const int lic_max = 10;/* 靜態變量 */ static int lisv_width = 10;

2. 函數

全局函數，以模塊名稱為前綴，單詞間首字母大寫，例如void CommInit();頭文件中聲明必須包含extern關鍵字。
局部函數，以模塊名稱與下劃線為前綴，單詞間首字母大寫；需在源文件中做前置聲明。

3. 宏

以模塊名稱為前綴，單詞間使用下劃線隔開，單詞字母為全大寫。

4. 全局常量

以模塊名稱為前綴，單詞間使用下劃線隔開，單詞字母為全大寫，除了編譯開關/頭文件等特殊應用，應避免使用下劃線開始和結尾的定義。

---

六、文件名

大模塊之間以文件夾隔開，以功能命名，源文件與頭文件一一對應。

---

七、可讀性

1. 算法優先級

注意運算符的優先級，并用括號明確表達式的操作順序，避免使用默認優先級。防止閱讀程序時產生誤解，防止因默認優先級與設計思想不符而導致程序錯誤。

2. 使用有意義的標識代替不易理解的數字

避免使用不易理解的數字，用有意義的標識來替代。

3. 少用技巧性很高的語句

不要使用難懂的技巧性很高的語句，除非很有必要時。高技巧語句不等于高效率的程序，實際上程序的效率關鍵在于算法。

錯誤示例——

*stat_poi++ += 1;*++stat_poi += 1;

正確示例——

*stat_poi += 1; stat_poi++;++stat_poi; *stat_poi += 1;

---

八、編程建議

1. 變量與結構

• 去掉沒有必要的公共變量；
• 仔細定義并明確公共變量的含義、作用、取值范圍及公共變量；
• 明確公共變量與操作此公共變量的函數或過程的關系，如訪問、修改及創建等；
• 當向公共變量傳遞數據時，要十分小心，防止賦予不合理的值或越界等現象發生；
• 防止局部變量與公共變量同名；
• 嚴禁使用未經初始化的變量作為右值；
• 構造僅有一個模塊或函數可以修改、創建，而其余有關模塊或函數只訪問的公共變量，防止多個不同模塊或函數都可以修改、創建同一個公共變量；
• 使用嚴格形式定義的、可移植的數據類型，盡量不要使用與具體硬件或軟件環境關系密切的變量；
• 結構的功能要單一，是針對一種事務的抽象；
• 不要設計面面俱到、非常靈活的數據結構；
• 不同結構間的關系不要過于復雜；
• 結構中元素的個數應適中，若結構中元素個數過多可考慮依據某種原則把元素組成不同的子結構，以減少原結構中元素的個數；
• 仔細設計結構中元素的布局與排列順序，使結構容易理解、節省占用空間、并減少引起誤用現象；
• 結構的設計要盡量考慮向前兼容和以后的版本升級，并為某些未來可能的應用保留余地；
• 留心具體語言及編譯器處理不用數據類型的原則及有關細節；
• 編程時，要注意數據類型的強制轉換；
• 對編譯系統默認的數據類型轉換也要有充分的認識；
• 盡量減少沒有必要的數據類型默認轉換與強制轉換；
• 合理的設計數據并使用自定義數據類型，避免數據間進行不必要的類型轉換；
• 對自定義數據類型進行恰當命名，使它成為自描述性的，以提高代碼可讀性。注意命名方式在同一項目中的統一性；
• 當聲明用于分布式環境或不同CPU間通信環境的數據結構時，必須考慮機器的字節順序、使用的位域及字節對齊等問題。

2. 函數與過程

• 對所調用函數的錯誤返回碼要仔細、全面的處理；
• 明確函數功能，精確（而不是近似）地實現函數設計；
• 編寫可重入函數時，應使用局部變量；
• 編寫可重入函數時，若使用全局變量，則應通過關中斷、信號量等手段對其加以保護；
• 在同一項目組應明確規定對接口函數參數的合法性檢測應由函數調用者負責；
• 防止將函數的參數作為工作變量；
• 函數的規模盡量限制在150行以內，不包括注釋和空行；
• 一個函數僅完成一個功能；
• 為簡單功能編寫函數；
• 不要設計多用途而面面俱到的函數；
• 函數的功能應該是可以預測的，保證輸入數據相同就應產生同樣的輸出；
• 盡量不要編寫依賴其它函數內部實現的函數；
• 避免設計多參數函數，不使用的參數從接口中去掉，函數參數不要超過4個；
• 非調度函數應減少或防止控制參數，盡量只使用數據參數；
• 檢查函數非參數輸入的有效性，如數據文件、公共變量等；
• 函數名應準確描述函數的功能，使用動賓詞組為執行某操作的函數命名。如果是OOP方法，可以只有動詞（名次是對象本身），避免使用無意義或含義不清的動詞為函數命名；
• 函數的返回值要清楚明了，讓使用者不容易忽視錯誤情況；
• 除非必要，最好不要把與函數返回值類型不同的變量，以編譯系統默認的轉換方式或強制的轉換方式作為返回值返回；
• 在調用函數填寫參數時，盡量減少沒有必要的默認數據類型轉換或強制數據類型轉換；
• 避免函數中不必要語句，防止程序中的垃圾代碼；
• 防止喊出或過程內出現隨機內聚，不要將沒有關聯或關聯很弱的語句放到同一個函數或過程中；
• 如果多段代碼執行同一功能，那么考慮將此段代碼構造成一個新的函數；
• 功能不明確、較小的函數，特別是僅有一個上級函數調用它時，應考慮把它合并到上級函數中，而不必單獨存在；
• 設計高扇入、合理扇出（<7）的函數；
• 減少函數本身或函數間的遞歸調用；
• 仔細分析模塊的功能及性能需求，并進一步細分，同時若有必要畫出有關數據流圖，據此來進行模塊的函數劃分與組織；
• 改進模塊中函數的結構，降低函數間的耦合度，并提高函數的獨立性以及代碼可讀性、效率和可維護性。優化函數結構時，要遵守以下原則——

1. 不能影響函數功能的實現；
2. 仔細考查模塊或函數出錯處理及模塊的性能要求并進行完善；
3. 通過分解或合并函數來改進軟件結構；
4. 考查函數的規模，過大的要進行分解；
5. 降低函數間接口的復雜度；
6. 不同層次的函數調用要有較合理的扇入、扇出；
7. 函數功能應可預測；
8. 提高函數內聚。

• 在多任務操作系統的環境下編譯，要注意函數可重入性的構造；
• 避免使用BOOL參數；
• 對于提供了返回值的函數，在引用時最好使用其返回值；
• 當一個過程（函數）匯總對較長變量（一般是結構體的成員）有較多引用時，可以用一個意義相當的宏代替。

3. 可測性

• 在同一個項目組或產品組內，要有一套統一的，為集成測試與系統聯調準備的調測開關及相關打印函數，并且要有詳細的說明；
• 在同一項目組或產品組內，調測打印出的信息串的格式要有統一的形式，信息串至少要有所在模塊名及行號；
• 編程的同時要為單元測試選擇恰當的測試點，并仔細構造測試代碼、測試用例，同時給出明確的注釋說明。測試代碼部分應作為（模塊中的）一個子模塊，以方便測試代碼在模塊中的安裝與拆卸（通過調測開關）；
• 在進行集成測試/系統聯調之前，要構造好測試環境、測試項目以及測試用例，同時仔細分析并優化測試用例，以提高測試效率；
• 使用斷言來發現軟件問題，提高代碼可測性；
• 用斷言來檢查程序正常運行時不應發生但在調測時有可能發生的非法情況；
• 不能用斷言來檢查程序正常運行時不應發生但在調測時有可能發生的非法情況；
• 對較為復雜的斷言加上明確的注釋；
• 用斷言確認函數的參數；
• 用斷言保證沒有定義的特性或功能不被使用；
• 用斷言對程序開發環境的假設進行檢查；
• 正式軟件產品中應把斷言及其它調測代碼去掉；
• 在軟件系統中設置與取消有關測試手段，不能對軟件實現的功能等產生影響；
• 用調測開關來切換軟件的Debug版和Release版，而不要同時存在Debug版本和Release版本的不同源文件，減少維護的難度；
• 在編寫代碼之前，應預先設計好程序調測與測試的方法和手段，并設計好各種調測開關和相應測試代碼；
• 調測開關應分為不同級別和類型；
• 編寫放錯程序，然后在處理錯誤之后可用斷言宣布發生錯誤。

4. 程序效率

• 在保證軟件系統的正確性、穩定性、可讀性以及可測性的前提下，提高代碼效率；
• 局部效率應為全局效率服務，不能因為提高局部效率而對全局效率造成影響；
• 通過對系統數據結構的劃分與組織的改進，以及對程序算法的優化來提高空間效率；
• 循環體內工作量最小化；
• 仔細分析有關算法，并進行優化；
• 仔細考查、分析系統及模塊處理輸出（如事務、消息等）的方式，并加以改進；
• 對模塊中函數的劃分及組織方式進行分析、優化，改進模塊中函數的組織結構，提高程序效率；
• 編程時，要隨時留心代碼效率；優化代碼時，要考慮周全；
• 不應花過多的時間拼命地提高調用不很頻繁的函數代碼效率；
• 要仔細地構造或直接用匯編編寫調用頻繁或性能要求極高的函數；
• 在保證程序質量的前提下，通過壓縮代碼量、去掉不必要代碼以及減少不必要的局部和全局變量，來提高空間效率；
• 在多重循環中，應將最忙的循環放在最內層；
• 盡量減少循環嵌套層次；
• 避免循環體內含判斷語句，應將循環語句置于判斷語句的代碼塊之中；
• 盡量用乘法或其它方法代替除法，特別是浮點運算中的除法；
• 不要一味追求緊湊的代碼。

5. 質量保證

• 軟件設計過程中構筑軟件質量；
• 代碼質量保證優先原則；

1. 正確性，指程序要實現設計要求的功能；
2. 穩定性、安全性，指程序穩定、安全、可靠；
3. 可測試性，指程序要具有良好的可測試性；
4. 規范/可讀性，指程序書寫風格、命名規則等要符合規范；
5. 全局效率，指軟件系統的整體效率；
6. 局部效率，指某個模塊/子模塊/函數的本身效率；
7. 個人表達方式/個人方便性，指個人編程習慣。

• 只引用屬于自己的存貯空間；
• 防止引用已經釋放的內存空間；
• 過程/函數中分配的內存，在過程/函數退出之前要釋放；
• 過程/函數中申請的文件句柄，在過程/函數退出之前要關閉；
• 防止內存操作越界；
• 認真處理程序所能遇到的各種出錯情況；
• 系統運行之初，要初始化有關變量及運行環境，防止未經初始化的變量被引用；
• 系統運行之初，要對加載到系統中的數據進行一致性檢查；
• 嚴謹隨意更改其它模塊或系統的有關設置和配置；
• 不能隨意改變與其它模塊的接口；
• 充分了解系統的接口之后，在使用系統提供的功能；
• 編程時，防止差1錯誤；
• 要時刻注意混淆的操作符，當寫完程序之后，應仔細檢測這些操作符；
• 有可能的話，if語句盡量加上else分支，對沒有else分支的語句要小心對待；switch語句必須有default分支；
• Unix下，多線程中的子線程退出必須采用主動退出方式；
• 不要濫用goto語句；
• 不使用與硬件或操作系統關系很大的語句，而使用建議的標準語句，以提高軟件的可移植性和可重用性；
• 除非為了滿足特殊需求，避免使用嵌入式匯編；
• 精心地構造、劃分子模塊，并按“接口”部分及“內核”部分合理地組織子模塊，以提高“內核”部分的可移植性和可重用性；
• 精心構造算法，并對其性能、效率進行測試；
• 對較關鍵的算法最好使用其它算法來確認；
• 時刻注意表達式是否會上溢、下溢；
• 使用變量時要注意其邊界值的情況；
• 留心程序機器碼大小（如指令空間大小、數據空間大小、堆棧空間大小等）是否超出系統有關限制；
• 為用戶提供良好的接口界面，是用戶能較充分地了解系統內部運行狀態及有關系統出錯情況；
• 系統應具有一定的容錯能力，對一些錯誤時間（如用戶誤操作等）能進行自動補救；
• 對一些具有危險性的操作代碼（如寫硬盤、刪數據等）要仔細考慮，防止對數據、硬件等的安全構成危害，以提高系統的安全性；
• 使用第三方提供的軟件集開發工具包或控件時，要注意以下幾點：

1. 充分了解應用接口、使用環境及使用時注意事項；
2. 不能過分相信其正確性；
3. 除非必要，不要使用不熟悉的第三方工具包與空間。

• 資源文件需要支持多語言版本，如果資源是對語言敏感的，應讓該資源與源代碼文件脫離。

6. 代碼編輯、編譯、審查

• 開編譯器的所有警告開發對程序進行編譯；
• 在產品軟件中，要統一編譯開關選項；
• 通過代碼走讀及審查方式對代碼進行檢查；
• 測試部測試產品之前，應對代碼進行抽查及評審；
• 編寫代碼時，完成功能模板及自測后及時提交版本庫；
• 同項目組內，最好使用相同的編譯器，并使用相同的設置選項；
• 要小心地使用編譯器提供的塊拷貝功能編程；
• 合理地設計軟件系統目錄，方便開發人員使用；
• 某些語句經編譯后產生警告，但如果你確認它是正確的，那么應通過某種手動去掉警告信息；
• 使用代碼檢查工具對源程序檢查；
• 使用軟件工具進行代碼審查。

7. 代碼測試、維護

• 元測試要求至少達到語句覆蓋；
• 單元測試開始要跟蹤每一條語句，并觀察數據流及變量的變化；
• 清理、整理或優化后的代碼要經過審查及測試；
• 代碼版本升級要經過嚴格測試；
• 使用工具軟件對代碼版本進行維護；
• 正式版本上軟件的任何修改都應有詳細的文檔記錄；
• 發現錯誤立即修改，并且要記錄下來；
• 關鍵的代碼在匯編級跟蹤；
• 仔細設計并分析測試用例，是測試用例覆蓋盡可能多的情況，以提高測試用例的效率；
• 盡可能模擬出程序的各種出錯情況，對出錯處理代碼進行充分的測試；
• 仔細測試代碼處理數據、變量的邊界情況；
• 保留測試信息，以便分析、總結經驗及進行更充分的測試；
• 不應通過“試”來解決問題，應尋找問題的根本原因；
• 對自動消失的錯誤進行分析，搞清楚錯誤是如何消失的；
• 修改錯誤不僅要治標，更要治本；
• 測試時應設法使很少發生的事件經常發生；
• 堅持在編碼階段就對代碼進行徹底的單元測試，不要等以后的測試工作來發現問題；
• 去除代碼運行的隨機性（如去掉無用的數據、代碼及盡可能防止并注意函數中的“內部寄存器”等），讓函數運行的結果可預測，并使出現的錯誤可再現。

8. 宏

• 用宏定義表達式時，要使用完備的括號；
• 將宏定義的多條表達式放在大括號中；
• 使用宏時，不允許參數發生變化；

---

C語言編程規范https://www.zhihu.com/video/1147146562961661952

視頻下載地址：https://pan.baidu.com/s/1iEifZDpV_A8R6xQAsi7fNw

相關文檔：華為技術有限公司C語言編程規范

總結

以上是生活随笔為你收集整理的华为c语言编程规范_C语言编程规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。