C規範【學習用】
阿新 • • 發佈：2019-01-08
華為技術有限公司內部技術規範C語言程式設計規範華為技術有限公司
Huawei Technologies Co., Ltd.
修訂宣告Revision declaration
本規範擬製與解釋部門：
本規範的相關係列規範或檔案：
相關國際規範或檔案一致性：
替代或作廢的其它規範或檔案：
相關規範或檔案的相互關係：
目 錄Table of Contents
0 規範制訂說明 ................................................................................................................................5
0.1
0.2 程式碼總體原則 .......................................................................................................................5
0.3 規範實施、解釋....................................................................................................................6
0.4
1 標頭檔案 ...........................................................................................................................................6
2 函式.............................................................................................................................................12
3 識別符號命名與定義.......................................................................................................................21
3.1 通用命名規則 .....................................................................................................................21
3.2 檔案命名規則 .....................................................................................................................23
3.3 變數命名規則 .....................................................................................................................23
3.4 函式命名規則 .....................................................................................................................24
3.5 巨集的命名規則 .....................................................................................................................24
4 變數.............................................................................................................................................25
5 巨集、常量......................................................................................................................................28
6 質量保證......................................................................................................................................32
7 程式效率......................................................................................................................................36
8 註釋.............................................................................................................................................39
9 排版與格式..................................................................................................................................44
10 表示式.....................................................................................................................................46
11 程式碼編輯、編譯 ......................................................................................................................49
12 可測性.....................................................................................................................................50
13 安全性.....................................................................................................................................51
13.1 字串操作安全..................................................................................................................51
13.2 整數安全.............................................................................................................................52
13.3 格式化輸出安全..................................................................................................................56
13.4 檔案I/O安全........................................................................................................................57
13.5 其它....................................................................................................................................59
14 單元測試.................................................................................................................................59
15 可移植性.................................................................................................................................60
16 業界程式設計規範..........................................................................................................................60
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第4頁,共61頁Page 4 , Total61
C語言程式設計規範
範 圍:
本規範適用於公司內使用C語言編碼的所有軟體。 本規範自發布之日起生效，以後新編寫的和修改的
程式碼應遵守本規範。
簡 介：
本規範制定了編寫C語言程式的基本原則、規則和建議。 從程式碼的清晰、簡潔、可測試、安全、程式效
率、可移植各個方面對C語言程式設計作出了具體指導。
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第5頁,共61頁Page 5 , Total61
0規範制訂說明
0.1 前言
為提高產品程式碼質量，指導廣大軟體開發人員編寫出簡潔、可維護、可靠、可測試、高效、可移植的
程式碼， 程式設計規範修訂工作組分析、總結了我司的各種典型編碼問題， 並參考了業界程式設計規範近年來的
成果，重新對我司1999年版程式設計規範進行了梳理、優化、重新整理，編寫了本規範。
本規範將分為完整版和精簡版，完整版將包括更多的樣例、規範的解釋以及參考材料(what & why)，
而精簡版將只包含規則部分(what)以便查閱。
在本規範的最後，列出了一些業界比較優秀的程式設計規範，作為延伸閱讀參考材料。
0.2 程式碼總體原則
1、清晰第一
清晰性是易於維護、易於重構的程式必需具備的特徵。 程式碼首先是給人讀的，好的程式碼應當可以像文
章一樣發聲朗誦出來。
目前軟體維護期成本佔整個生命週期成本的40%~90%。根據業界經驗，維護期變更程式碼的成本，小型系
統是開發期的5倍，大型系統（100萬行程式碼以上）可以達到100倍。業界的調查指出，開發組平均大約
一半的人力用於彌補過去的錯誤，而不是新增新的功能來幫助公司提高競爭力。
“程式必須為閱讀它的人而編寫，只是順便用於機器執行。” ——Harold Abelson 和 Gerald Jay
Sussman
“編寫程式應該以人為本，計算機第二。” ——Steve McConnell
本規範通過後文中的原則（如頭優秀的程式碼可以自我解釋，不通過註釋即可輕易讀懂/標頭檔案中適合放
置介面的宣告，不適合放置實現/除了常見的通用縮寫以外，不使用單詞縮寫，不得使用漢語拼音）、
規則（如防止區域性變數與全域性變數同名）等說明清晰的重要性。
一般情況下，程式碼的可閱讀性高於效能，只有確定性能是瓶頸時，才應該主動優化。
2、簡潔為美
簡潔就是易於理解並且易於實現。 程式碼越長越難以看懂，也就越容易在修改時引入錯誤。寫的程式碼越
多，意味著出錯的地方越多，也就意味著程式碼的可靠性越低。因此，我們提倡大家通過編寫簡潔明瞭
的程式碼來提升程式碼可靠性。
廢棄的程式碼(沒有被呼叫的函式和全域性變數)要及時清除，重複程式碼應該儘可能提煉成函式。
本規範通過後文中的原則（如檔案應當職責單一/一個函式僅完成一件功能）、規則（重複程式碼應該盡
可能提煉成函式/避免函式過長，新增函式不超過50行）等說明簡潔的重要性。
3、選擇合適的風格，與程式碼原有風格保持一致
產品所有人共同分享同一種風格所帶來的好處，遠遠超出為了統一而付出的代價。在公司已有編碼規
範的指導下，審慎地編排程式碼以使程式碼儘可能清晰，是一項非常重要的技能。 如果重構/修改其他風格
的程式碼時，比較明智的做法是根據現有程式碼的現有風格繼續編寫程式碼，或者使用格式轉換工具進行轉
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第6頁,共61頁Page 6 , Total61
換成公司內部風格。
0.3 規範實施、解釋
本規範制定了編寫C語言程式的基本原則、規則和建議。
本規範適用於公司內使用C語言編碼的所有軟體。本規範自發布之日起生效，對以後新編寫的和修改
的程式碼應遵守本規範。
本規範由質量體系釋出和維護。實施中遇到問題，可以到論壇
http://hi3ms.huawei.com/group/1735/threads.html上討論。
在某些情況下（如BSP軟體）需要違反本文件給出的規則時，相關團隊必須通過一個正式的流程來評
審、決策規則違反的部分，個體程式設計師不得違反本規範中的相關規則。
0.4 術語定義
原則：程式設計時必須堅持的指導思想。
規則：程式設計時強制必須遵守的約定。
建議：程式設計時必須加以考慮的約定。
說明：對此原則/規則/建議進行必要的解釋。
示例：對此原則/規則/建議從正、反兩個方面給出例子。
延伸閱讀材料：建議進一步閱讀的參考材料。
1標頭檔案
背景
對於C語言來說，標頭檔案的設計體現了大部分的系統設計。 不合理的標頭檔案佈局是編譯時間過長的根
因，不合理的標頭檔案實際上不合理的設計。
術語定義：
依賴：本章節特指編譯依賴。若x.h包含了y.h，則稱作x依賴y。依賴關係會進行傳導，如x.h包含y.h，
而y.h又包含了z.h，則x通過y依賴了z。依賴將導致編譯時間的上升。雖然依賴是不可避免的，也是必
須的，但是不良的設計會導致整個系統的依賴關係無比複雜，使得任意一個檔案的修改都要重新編譯
整個系統，導致編譯時間巨幅上升。
在一個設計良好的系統中， 修改一個檔案，只需要重新編譯數個，甚至是一個檔案。
某產品曾經做過一個實驗，把所有函式的實現通過工具註釋掉，其編譯時間只減少了不到10%，究其原
因，在於A包含B， B包含C， C包含D，最終幾乎每一個原始檔都包含了專案組所有的標頭檔案，從而導致
絕大部分編譯時間都花在解析標頭檔案上。
某產品更有一個“優秀實踐”，用於將.c檔案通過工具合併成一個比較大的.c檔案，從而大幅度提高
編譯效率。其根本原因還是在於通過合併.c檔案減少了標頭檔案解析次數。但是，這樣的“優秀實踐”
是對合理劃分.c檔案的一種破壞。
大部分產品修改一處程式碼，都得需要編譯整個工程，對於TDD之類的實踐，要求對於模組級別的編譯時
間控制在秒級，即使使用分散式編譯也難以實現，最終仍然需要合理的劃分標頭檔案、以及標頭檔案之間
的包含關係， 從根本上降低編譯時間。
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第7頁,共61頁Page 7 , Total61
《google C++ Style Guide》 1.2 標頭檔案依賴 章節也給出了類似的闡述：
若包含了標頭檔案aa.h，則就引入了新的依賴： 一旦aa.h被修改，任何直接和間接包含aa.h程式碼都會被
重新編譯。如果aa.h又包含了其他標頭檔案如bb.h，那麼bb.h的任何改變都將導致所有包含了aa.h的代
碼被重新編譯，在敏捷開發方式下，程式碼會被頻繁構建，漫長的編譯時間將極大的阻礙頻繁構建。因
此，我們傾向於減少包含標頭檔案，尤其是在標頭檔案中包含標頭檔案，以控制改動程式碼後的編譯時間。
合理的標頭檔案劃分體現了系統設計的思想，但是從程式設計規範的角度看，仍然有一些通用的方法，用來
合理規劃標頭檔案。本章節介紹的一些方法，對於合理規劃標頭檔案會有一定的幫助。
原則1.1 標頭檔案中適合放置介面的宣告，不適合放置實現。
說明： 標頭檔案是模組（Module）或單元（Unit）的對外介面。標頭檔案中應放置對外部的宣告，如對外
提供的函式宣告、巨集定義、型別定義等。
內部使用的函式（相當於類的私有方法）宣告不應放在標頭檔案中。
內部使用的巨集、列舉、結構定義不應放入標頭檔案中。
變數定義不應放在標頭檔案中，應放在.c檔案中。
變數的宣告儘量不要放在標頭檔案中，亦即儘量不要使用全域性變數作為介面。變數是模組或單元的內部
實現細節，不應通過在標頭檔案中宣告的方式直接暴露給外部，應通過函式介面的方式進行對外暴露。 即
使必須使用全域性變數，也只應當在.c中定義全域性變數，在.h中僅宣告變數為全域性的。
延伸閱讀材料： 《C語言介面與實現》 （David R. Hanson 著 傅蓉 周鵬 張昆琪 權威 譯 機械工業出
版社 2004年1月） （英文版： "C Interfaces and Implementations"）
原則1.2 標頭檔案應當職責單一。
說明：標頭檔案過於複雜，依賴過於複雜是導致編譯時間過長的主要原因。 很多現有程式碼中標頭檔案過大，
職責過多， 再加上迴圈依賴的問題，可能導致為了在.c中使用一個巨集，而包含十幾個標頭檔案。
示例： 如下是某平臺定義WORD型別的標頭檔案：
#include <VXWORKS.H>
#include <KERNELLIB.H>
#include <SEMLIB.H>
#include <INTLIB.H>
#include <TASKLIB.H>
#include <MSGQLIB.H>
#include <STDARG.H>
#include <FIOLIB.H>
#include <STDIO.H>
#include <STDLIB.H>
#include <CTYPE.H>
#include <STRING.H>
#include <ERRNOLIB.H>
#include <TIMERS.H>
#include <MEMLIB.H>
#include <TIME.H>
#include <WDLIB.H>
#include <SYSLIB.H>
#include <TASKHOOKLIB.H>
#include <REBOOTLIB.H>
…
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第8頁,共61頁Page 8 , Total61
typedef unsigned short WORD;
…
這個標頭檔案不但定義了基本資料型別WORD，還包含了stdio.h syslib.h等等不常用的標頭檔案。如果工
程中有10000個原始檔，而其中100個原始檔使用了stdio.h的printf，由於上述標頭檔案的職責過於龐大，
而WORD又是每一個檔案必須包含的，從而導致stdio.h/syslib.h等可能被不必要的展開了9900次，大
大增加了工程的編譯時間。
原則1.3 標頭檔案應向穩定的方向包含。
說明： 標頭檔案的包含關係是一種依賴，一般來說，應當讓不穩定的模組依賴穩定的模組，從而當不穩
定的模組發生變化時，不會影響（編譯）穩定的模組。
就我們的產品來說，依賴的方向應該是： 產品依賴於平臺，平臺依賴於標準庫。 某產品線平臺的程式碼
中已經包含了產品的標頭檔案，導致平臺無法單獨編譯、釋出和測試， 是一個非常糟糕的反例。
除了不穩定的模組依賴於穩定的模組外，更好的方式是兩個模組共同依賴於介面，這樣任何一個模組
的內部實現更改都不需要重新編譯另外一個模組。在這裡，我們假設介面本身是最穩定的。
延伸閱讀材料： 編者推薦開發人員使用“依賴倒置”原則，即由使用者制定介面，服務提供者實現介面，
更具體的描述可以參見《敏捷軟體開發：原則、模式與實踐》 （Robert C.Martin 著 鄧輝 譯 清
華大學出版社2003年9月） 的第二部分“敏捷設計”章節。
規則1.1 每一個.c檔案應有一個同名.h檔案，用於宣告需要對外公開的介面。
說明： 如果一個.c檔案不需要對外公佈任何介面，則其就不應當存在，除非它是程式的入口，如main
函式所在的檔案。
現有某些產品中，習慣一個.c檔案對應兩個標頭檔案，一個用於存放對外公開的介面，一個用於存放內
部需要用到的定義、宣告等，以控制.c檔案的程式碼行數。編者不提倡這種風格。這種風格的根源在於
原始檔過大，應首先考慮拆分.c檔案，使之不至於太大。另外，一旦把私有定義、宣告放到獨立的頭
檔案中，就無法從技術上避免別人include之，難以保證這些定義最後真的只是私有的。
本規則反過來並不一定成立。有些特別簡單的標頭檔案，如命令ID定義標頭檔案，不需要有對應的.c存在。
示例：對於如下場景，如在一個.c中存在函式呼叫關係：
void foo()
{
bar();
}
void bar()
{
Do something;
}
必須在foo之前宣告bar，否則會導致編譯錯誤。
這一類的函式宣告，應當在.c的頭部宣告，並宣告為static的，如下：
static void bar();
void foo()
{
bar();
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第9頁,共61頁Page 9 , Total61
}
void bar()
{
Do something;
}
規則1.2 禁止標頭檔案迴圈依賴。
說明： 標頭檔案迴圈依賴，指a.h包含b.h， b.h包含c.h， c.h包含a.h之類導致任何一個頭檔案修改，都
導致所有包含了a.h/b.h/c.h的程式碼全部重新編譯一遍。而如果是單向依賴，如a.h包含b.h， b.h包含
c.h，而c.h不包含任何標頭檔案，則修改a.h不會導致包含了b.h/c.h的原始碼重新編譯。
規則1.3 .c/.h檔案禁止包含用不到的標頭檔案。
說明： 很多系統中標頭檔案包含關係複雜，開發人員為了省事起見，可能不會去一一鑽研，直接包含一
切想到的標頭檔案，甚至有些產品乾脆釋出了一個god.h，其中包含了所有標頭檔案，然後釋出給各個專案
組使用，這種只圖一時省事的做法，導致整個系統的編譯時間進一步惡化，並對後來人的維護造成了
巨大的麻煩。
規則1.4 標頭檔案應當自包含。
說明： 簡單的說，自包含就是任意一個頭檔案均可獨立編譯。 如果一個檔案包含某個標頭檔案，還要包
含另外一個頭檔案才能工作的話，就會增加交流障礙，給這個標頭檔案的使用者增添不必要的負擔。
示例：
如果a.h不是自包含的，需要包含b.h才能編譯，會帶來的危害：
每個使用a.h標頭檔案的.c檔案，為了讓引入的a.h的內容編譯通過，都要包含額外的標頭檔案b.h。
額外的標頭檔案b.h必須在a.h之前進行包含，這在包含順序上產生了依賴。
注意：該規則需要與“.c/.h檔案禁止包含用不到的標頭檔案”規則一起使用，不能為了讓a.h自包含，
而在a.h中包含不必要的標頭檔案。 a.h要剛剛可以自包含，不能在a.h中多包含任何滿足自包含之外的其
他標頭檔案。
規則1.5 總是編寫內部#include保護符（#define 保護） 。
說明：多次包含一個頭檔案可以通過認真的設計來避免。如果不能做到這一點，就需要採取阻止頭文
件內容被包含多於一次的機制。
通常的手段是為每個檔案配置一個巨集，當頭檔案第一次被包含時就定義這個巨集，並在標頭檔案被再次包
含時使用它以排除檔案內容。
所有標頭檔案都應當使用#define 防止標頭檔案被多重包含，命名格式為FILENAME_H，為了保證唯一性，
更好的命名是PROJECTNAME_PATH_FILENAME_H。
注：沒有在巨集最前面加上“_"，即使用FILENAME_H代替_FILENAME_H_，是因為一般以"_"和”__"開頭的
識別符號為系統保留或者標準庫使用，在有些靜態檢查工具中，若全域性可見的識別符號以"_"開頭會給出告
警。
定義包含保護符時，應該遵守如下規則：
1）保護符使用唯一名稱；
2）不要在受保護部分的前後放置程式碼或者註釋。
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第10頁,共61頁Page 10 , Total61
示例：假定VOS工程的timer模組的timer.h，其目錄為VOS/include/timer/timer.h,應按如下方式保護：
#ifndef VOS_INCLUDE_TIMER_TIMER_H
#define VOS_INCLUDE_TIMER_TIMER_H
...
#endif
也可以使用如下簡單方式保護:
#ifndef TIMER_H
#define TIMER_H
..
#endif
使用C++前處理器展開b.h，將會得到
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第11頁,共61頁Page 11 , Total61
extern "C" {
void foo(int);
void b();
}
按照a.h作者的本意，函式foo是一個C++自由函式，其連結規範為"C++"。但在b.h中，由於#include
"a.h"被放到了extern "C" { }的內部，函式foo的連結規範被不正確地更改了。
示例： 錯誤的使用方式：
extern “C”
{
#include “xxx.h”
...
}
正確的使用方式：
#include “xxx.h”
extern “C”
{
...
}
建議1.1 一個模組通常包含多個.c檔案，建議放在同一個目錄下，目錄名即為模組名。為方便外部使
用者，建議每一個模組提供一個.h，檔名為目錄名。
說明：需要注意的是，這個.h並不是簡單的包含所有內部的.h，它是為了模組使用者的方便，對外整
體提供的模組介面。
以Google test（簡稱GTest）為例， GTest作為一個整體對外提供C++單元測試框架，其1.5版本的gtest
工程下有6個原始檔和12個頭檔案。但是它對外只提供一個gtest.h，只要包含gtest.h即可使用GTest
提供的所有對外提供的功能，使用者不必關係GTest內部各個檔案的關係，即使以後GTest的內部實現
改變了，比如把一個原始檔c拆成兩個原始檔，使用者也不必關心，甚至如果對外功能不變，連重新編
譯都不需要。
對於有些模組，其內部功能相對鬆散，可能並不一定需要提供這個.h，而是直接提供各個子模組或者.c
的標頭檔案。
比如產品普遍使用的VOS，作為一個大模組，其內部有很多子模組，他們之間的關係相對比較鬆散，就
不適合提供一個vos.h。而VOS的子模組，如Memory（僅作舉例說明，與實際情況可能有所出入），其
內部實現高度內聚，雖然其內部實現可能有多個.c和.h，但是對外只需要提供一個Memory.h宣告介面。
建議1.2 如果一個模組包含多個子模組，則建議每一個子模組提供一個對外的.h，檔名為子模組名。
說明：降低介面使用者的編寫難度。
建議1.3 標頭檔案不要使用非習慣用法的副檔名，如.inc。
說明：目前很多產品中使用了.inc作為標頭檔案副檔名，這不符合c語言的習慣用法。在使用.inc作為頭
副檔名的產品，習慣上用於標識此標頭檔案為私有標頭檔案。但是從產品的實際程式碼來看，這一條並
沒有被遵守，一個.inc檔案被多個.c包含比比皆是。本規範不提倡將私有定義單獨放在標頭檔案中，具
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第12頁,共61頁Page 12 , Total61
體見 規則1.1。
除此之外，使用.inc還導致source insight、 Visual stduio等IDE工具無法識別其為標頭檔案，導致很
多功能不可用，如“跳轉到變數定義處”。雖然可以通過配置，強迫IDE識別.inc為標頭檔案，但是有些
軟體無法配置，如Visual Assist只能識別.h而無法通過配置識別.inc。
建議1.4 同一產品統一包含標頭檔案排列方式。
說明：常見的包含標頭檔案排列方式： 功能塊排序、檔名升序、穩定度排序。
示例1：
以升序方式排列標頭檔案可以避免標頭檔案被重複包含，如：
#include <a.h>
#include <b.h>
#include <c/d.h>
#include <c/e.h>
#include <f.h>
示例2：
以穩定度排序， 建議將不穩定的標頭檔案放在前面，如把產品的標頭檔案放在平臺的標頭檔案前面，如下：
#include <product.h>
#include <platform.h>
相對來說， product.h修改的較為頻繁，如果有錯誤，不必編譯platform.h就可以發現product.h的錯
誤，可以部分減少編譯時間。
2函式
背景
函式設計的精髓：編寫整潔函式，同時把程式碼有效組織起來。
整潔函式要求：程式碼簡單直接、不隱藏設計者的意圖、用乾淨利落的抽象和直截了當的控制語句將函
數有機組織起來。
程式碼的有效組織包括：邏輯層組織和物理層組織兩個方面。邏輯層，主要是把不同功能的函式通過某
種聯絡組織起來，主要關注模組間的介面，也就是模組的架構。物理層，無論使用什麼樣的目錄或者
名字空間等，需要把函式用一種標準的方法組織起來。例如：設計良好的目錄結構、函式名字、檔案
組織等，這樣可以方便查詢。
原則2.1 一個函式僅完成一件功能。
說明：一個函式實現多個功能給開發、使用、維護都帶來很大的困難。
將沒有關聯或者關聯很弱的語句放到同一函式中，會導致函式職責不明確，難以理解，難以測試和改
動。
案例： realloc。在標準C語言中， realloc是一個典型的不良設計。這個函式基本功能是重新分配記憶體，
但它承擔了太多的其他任務：如果傳入的指標引數為NULL就分配記憶體，如果傳入的大小引數為0就釋放
記憶體，如果可行則就地重新分配，如果不行則移到其他地方分配。如果沒有足夠可用的記憶體用來完成
重新分配（擴大原來的記憶體塊或者分配新的記憶體塊），則返回NULL，而原來的記憶體塊保持不變。這個
函式不易擴充套件，容易導致問題。例如下面程式碼容易導致記憶體洩漏：
char *buffer = (char *)malloc(XXX_SIZE);
.....
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第13頁,共61頁Page 13 , Total61
buffer = (char *)realloc(buffer, NEW_SIZE);
如果沒有足夠可用的記憶體用來完成重新分配，函式返回為NULL，導致buffer原來指向的記憶體被丟失。
延伸閱讀材料：《敏捷軟體開發：原則、模式與實踐》 第八章，單一職責原則(SRP)
原則2.2 重複程式碼應該儘可能提煉成函式。
說明：重複程式碼提煉成函式可以帶來維護成本的降低。
重複程式碼是我司不良程式碼最典型的特徵之一。在“程式碼能用就不改”的指導原則之下，大量的煙囪式
設計及其實現充斥著各產品程式碼之中。新需求增加帶來的程式碼拷貝和修改，隨著時間的遷移，產品中
堆砌著許多類似或者重複的程式碼。
專案組應當使用程式碼重複度檢查工具，在持續整合環境中持續檢查程式碼重複度指標變化趨勢，並對新
增重複程式碼及時重構。當一段程式碼重複兩次時，即應考慮消除重複，當代碼重複超過三次時，應當立
刻著手消除重複。
一般情況下，可以通過提煉函式的形式消除重複程式碼。
示例：
UC ccb_aoc_process( )
{
... ...
struct AOC_E1_E7 aoc_e1_e7;
aoc_e1_e7.aoc = 0;
aoc_e1_e7.e[0] = 0;
... ... //aoc_e1_e7.e[i]從到賦值，下同
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
... ...
if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
}
... ...
}
else if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第14頁,共61頁Page 14 , Total61
aoc_e1_e7.tariff_rate = 0;
}
ccb_caller_e1 = aoc_e1_e7.e[0];
... ...
ccb_caller_e7 = aoc_e1_e7.e[6];
ccb_caller_tariff_rate = aoc_e1_e7.tariff_rate;
... ...
}
... ...
if (xxx)
{
if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
}
... ...
}
else if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
}
ccb_caller_e1 = aoc_e1_e7.e[0];
... ...
ccb_caller_e7 = aoc_e1_e7.e[6];
ccb_caller_tariff_rate = aoc_e1_e7.tariff_rate;
... ...
}
return 1;
}
else
{
return 0;
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第15頁,共61頁Page 15 , Total61
}
}
刺鼻的程式碼壞味充斥著這個函式。紅色字型的部分是簡單的程式碼重複，粗體字部分是程式碼結構的重複，
將重複部分提煉成一個函式即可消除重複。
規則2.1 避免函式過長，新增函式不超過50行（非空非註釋行） 。
說明：本規則僅對新增函式做要求，對已有函式修改時，建議不增加程式碼行。
過長的函式往往意味著函式功能不單一，過於複雜（參見原則2.1：一個函式只完成一個功能）。
函式的有效程式碼行數，即NBNC（非空非註釋行）應當在[1， 50]區間。
例外：某些實現演算法的函式，由於演算法的聚合性與功能的全面性，可能會超過50行。
延伸閱讀材料： 業界普遍認為一個函式的程式碼行不要超過一個螢幕，避免來回翻頁影響閱讀；一般的
程式碼度量工具建議都對此進行檢查，例如Logiscope的函式度量： "Number of Statement" （函式中的
可執行語句數）建議不超過20行， QA C建議一個函式中的所有行數（包括註釋和空白行）不超過50行。
規則2.2 避免函式的程式碼塊巢狀過深，新增函式的程式碼塊巢狀不超過4層。
說明：本規則僅對新增函式做要求，對已有的程式碼建議不增加巢狀層次。
函式的程式碼塊巢狀深度指的是函式中的程式碼控制塊（例如： if、 for、 while、 switch等）之間互相包
含的深度。每級巢狀都會增加閱讀程式碼時的腦力消耗，因為需要在腦子裡維護一個“棧”（比如，進
入條件語句、 進入迴圈„„）。應該做進一步的功能分解，從而避免使程式碼的閱讀者一次記住太多的
上下文。優秀程式碼參考值： [1, 4]。
示例：如下程式碼巢狀深度為5。
void serial (void)
{
if (!Received)
{
TmoCount = 0;
switch
Huawei Technologies Co., Ltd.
修訂宣告Revision declaration
本規範擬製與解釋部門：
本規範的相關係列規範或檔案：
相關國際規範或檔案一致性：
替代或作廢的其它規範或檔案：
相關規範或檔案的相互關係：
| 規範號 | 主要起草部門專家 | 主要評審部門專家 | 修訂情況 |
| DKBAxxxx.x-xxxx.xx | PSST質量部： 郭曙光00121837 網路： 張偉00118807 周燦00056781 王晶00041937 陳藝彪00036913 IP開發部： 薛治00038309 核心網： 張小林00058208 王德喜00040674 李明勝00042021 軟體公司： 文 滔00119601 無線： 劉愛華00162172 譚洪00162654 | PSST質量部： 李重霄00117374 郭永生00120218 核心網： 張進柏00120359 中研： 張建保00116237 無線： 蘇光牛00118740 鄭銘00118617 陶永祥00120482 軟體公司： 周代兵00120359 劉心紅00118478 朱文琦00172539 網路： 王玎00168059 黃維東49827 IP開發部： 饒遠00152313 |
目 錄Table of Contents
0 規範制訂說明 ................................................................................................................................5
0.1
0.2 程式碼總體原則 .......................................................................................................................5
0.3 規範實施、解釋....................................................................................................................6
0.4
1 標頭檔案 ...........................................................................................................................................6
2 函式.............................................................................................................................................12
3 識別符號命名與定義.......................................................................................................................21
3.1 通用命名規則 .....................................................................................................................21
3.2 檔案命名規則 .....................................................................................................................23
3.3 變數命名規則 .....................................................................................................................23
3.4 函式命名規則 .....................................................................................................................24
3.5 巨集的命名規則 .....................................................................................................................24
4 變數.............................................................................................................................................25
5 巨集、常量......................................................................................................................................28
6 質量保證......................................................................................................................................32
7 程式效率......................................................................................................................................36
8 註釋.............................................................................................................................................39
9 排版與格式..................................................................................................................................44
10 表示式.....................................................................................................................................46
11 程式碼編輯、編譯 ......................................................................................................................49
12 可測性.....................................................................................................................................50
13 安全性.....................................................................................................................................51
13.1 字串操作安全..................................................................................................................51
13.2 整數安全.............................................................................................................................52
13.3 格式化輸出安全..................................................................................................................56
13.4 檔案I/O安全........................................................................................................................57
13.5 其它....................................................................................................................................59
14 單元測試.................................................................................................................................59
15 可移植性.................................................................................................................................60
16 業界程式設計規範..........................................................................................................................60
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第4頁,共61頁Page 4 , Total61
C語言程式設計規範
範 圍:
本規範適用於公司內使用C語言編碼的所有軟體。 本規範自發布之日起生效，以後新編寫的和修改的
程式碼應遵守本規範。
簡 介：
本規範制定了編寫C語言程式的基本原則、規則和建議。 從程式碼的清晰、簡潔、可測試、安全、程式效
率、可移植各個方面對C語言程式設計作出了具體指導。
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第5頁,共61頁Page 5 , Total61
0規範制訂說明
0.1 前言
為提高產品程式碼質量，指導廣大軟體開發人員編寫出簡潔、可維護、可靠、可測試、高效、可移植的
程式碼， 程式設計規範修訂工作組分析、總結了我司的各種典型編碼問題， 並參考了業界程式設計規範近年來的
成果，重新對我司1999年版程式設計規範進行了梳理、優化、重新整理，編寫了本規範。
本規範將分為完整版和精簡版，完整版將包括更多的樣例、規範的解釋以及參考材料(what & why)，
而精簡版將只包含規則部分(what)以便查閱。
在本規範的最後，列出了一些業界比較優秀的程式設計規範，作為延伸閱讀參考材料。
0.2 程式碼總體原則
1、清晰第一
清晰性是易於維護、易於重構的程式必需具備的特徵。 程式碼首先是給人讀的，好的程式碼應當可以像文
章一樣發聲朗誦出來。
目前軟體維護期成本佔整個生命週期成本的40%~90%。根據業界經驗，維護期變更程式碼的成本，小型系
統是開發期的5倍，大型系統（100萬行程式碼以上）可以達到100倍。業界的調查指出，開發組平均大約
一半的人力用於彌補過去的錯誤，而不是新增新的功能來幫助公司提高競爭力。
“程式必須為閱讀它的人而編寫，只是順便用於機器執行。” ——Harold Abelson 和 Gerald Jay
Sussman
“編寫程式應該以人為本，計算機第二。” ——Steve McConnell
本規範通過後文中的原則（如頭優秀的程式碼可以自我解釋，不通過註釋即可輕易讀懂/標頭檔案中適合放
置介面的宣告，不適合放置實現/除了常見的通用縮寫以外，不使用單詞縮寫，不得使用漢語拼音）、
規則（如防止區域性變數與全域性變數同名）等說明清晰的重要性。
一般情況下，程式碼的可閱讀性高於效能，只有確定性能是瓶頸時，才應該主動優化。
2、簡潔為美
簡潔就是易於理解並且易於實現。 程式碼越長越難以看懂，也就越容易在修改時引入錯誤。寫的程式碼越
多，意味著出錯的地方越多，也就意味著程式碼的可靠性越低。因此，我們提倡大家通過編寫簡潔明瞭
的程式碼來提升程式碼可靠性。
廢棄的程式碼(沒有被呼叫的函式和全域性變數)要及時清除，重複程式碼應該儘可能提煉成函式。
本規範通過後文中的原則（如檔案應當職責單一/一個函式僅完成一件功能）、規則（重複程式碼應該盡
可能提煉成函式/避免函式過長，新增函式不超過50行）等說明簡潔的重要性。
3、選擇合適的風格，與程式碼原有風格保持一致
產品所有人共同分享同一種風格所帶來的好處，遠遠超出為了統一而付出的代價。在公司已有編碼規
範的指導下，審慎地編排程式碼以使程式碼儘可能清晰，是一項非常重要的技能。 如果重構/修改其他風格
的程式碼時，比較明智的做法是根據現有程式碼的現有風格繼續編寫程式碼，或者使用格式轉換工具進行轉
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第6頁,共61頁Page 6 , Total61
換成公司內部風格。
0.3 規範實施、解釋
本規範制定了編寫C語言程式的基本原則、規則和建議。
本規範適用於公司內使用C語言編碼的所有軟體。本規範自發布之日起生效，對以後新編寫的和修改
的程式碼應遵守本規範。
本規範由質量體系釋出和維護。實施中遇到問題，可以到論壇
http://hi3ms.huawei.com/group/1735/threads.html上討論。
在某些情況下（如BSP軟體）需要違反本文件給出的規則時，相關團隊必須通過一個正式的流程來評
審、決策規則違反的部分，個體程式設計師不得違反本規範中的相關規則。
0.4 術語定義
原則：程式設計時必須堅持的指導思想。
規則：程式設計時強制必須遵守的約定。
建議：程式設計時必須加以考慮的約定。
說明：對此原則/規則/建議進行必要的解釋。
示例：對此原則/規則/建議從正、反兩個方面給出例子。
延伸閱讀材料：建議進一步閱讀的參考材料。
1標頭檔案
背景
對於C語言來說，標頭檔案的設計體現了大部分的系統設計。 不合理的標頭檔案佈局是編譯時間過長的根
因，不合理的標頭檔案實際上不合理的設計。
術語定義：
依賴：本章節特指編譯依賴。若x.h包含了y.h，則稱作x依賴y。依賴關係會進行傳導，如x.h包含y.h，
而y.h又包含了z.h，則x通過y依賴了z。依賴將導致編譯時間的上升。雖然依賴是不可避免的，也是必
須的，但是不良的設計會導致整個系統的依賴關係無比複雜，使得任意一個檔案的修改都要重新編譯
整個系統，導致編譯時間巨幅上升。
在一個設計良好的系統中， 修改一個檔案，只需要重新編譯數個，甚至是一個檔案。
某產品曾經做過一個實驗，把所有函式的實現通過工具註釋掉，其編譯時間只減少了不到10%，究其原
因，在於A包含B， B包含C， C包含D，最終幾乎每一個原始檔都包含了專案組所有的標頭檔案，從而導致
絕大部分編譯時間都花在解析標頭檔案上。
某產品更有一個“優秀實踐”，用於將.c檔案通過工具合併成一個比較大的.c檔案，從而大幅度提高
編譯效率。其根本原因還是在於通過合併.c檔案減少了標頭檔案解析次數。但是，這樣的“優秀實踐”
是對合理劃分.c檔案的一種破壞。
大部分產品修改一處程式碼，都得需要編譯整個工程，對於TDD之類的實踐，要求對於模組級別的編譯時
間控制在秒級，即使使用分散式編譯也難以實現，最終仍然需要合理的劃分標頭檔案、以及標頭檔案之間
的包含關係， 從根本上降低編譯時間。
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第7頁,共61頁Page 7 , Total61
《google C++ Style Guide》 1.2 標頭檔案依賴 章節也給出了類似的闡述：
若包含了標頭檔案aa.h，則就引入了新的依賴： 一旦aa.h被修改，任何直接和間接包含aa.h程式碼都會被
重新編譯。如果aa.h又包含了其他標頭檔案如bb.h，那麼bb.h的任何改變都將導致所有包含了aa.h的代
碼被重新編譯，在敏捷開發方式下，程式碼會被頻繁構建，漫長的編譯時間將極大的阻礙頻繁構建。因
此，我們傾向於減少包含標頭檔案，尤其是在標頭檔案中包含標頭檔案，以控制改動程式碼後的編譯時間。
合理的標頭檔案劃分體現了系統設計的思想，但是從程式設計規範的角度看，仍然有一些通用的方法，用來
合理規劃標頭檔案。本章節介紹的一些方法，對於合理規劃標頭檔案會有一定的幫助。
原則1.1 標頭檔案中適合放置介面的宣告，不適合放置實現。
說明： 標頭檔案是模組（Module）或單元（Unit）的對外介面。標頭檔案中應放置對外部的宣告，如對外
提供的函式宣告、巨集定義、型別定義等。
內部使用的函式（相當於類的私有方法）宣告不應放在標頭檔案中。
內部使用的巨集、列舉、結構定義不應放入標頭檔案中。
變數定義不應放在標頭檔案中，應放在.c檔案中。
變數的宣告儘量不要放在標頭檔案中，亦即儘量不要使用全域性變數作為介面。變數是模組或單元的內部
實現細節，不應通過在標頭檔案中宣告的方式直接暴露給外部，應通過函式介面的方式進行對外暴露。 即
使必須使用全域性變數，也只應當在.c中定義全域性變數，在.h中僅宣告變數為全域性的。
延伸閱讀材料： 《C語言介面與實現》 （David R. Hanson 著 傅蓉 周鵬 張昆琪 權威 譯 機械工業出
版社 2004年1月） （英文版： "C Interfaces and Implementations"）
原則1.2 標頭檔案應當職責單一。
說明：標頭檔案過於複雜，依賴過於複雜是導致編譯時間過長的主要原因。 很多現有程式碼中標頭檔案過大，
職責過多， 再加上迴圈依賴的問題，可能導致為了在.c中使用一個巨集，而包含十幾個標頭檔案。
示例： 如下是某平臺定義WORD型別的標頭檔案：
#include <VXWORKS.H>
#include <KERNELLIB.H>
#include <SEMLIB.H>
#include <INTLIB.H>
#include <TASKLIB.H>
#include <MSGQLIB.H>
#include <STDARG.H>
#include <FIOLIB.H>
#include <STDIO.H>
#include <STDLIB.H>
#include <CTYPE.H>
#include <STRING.H>
#include <ERRNOLIB.H>
#include <TIMERS.H>
#include <MEMLIB.H>
#include <TIME.H>
#include <WDLIB.H>
#include <SYSLIB.H>
#include <TASKHOOKLIB.H>
#include <REBOOTLIB.H>
…
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第8頁,共61頁Page 8 , Total61
typedef unsigned short WORD;
…
這個標頭檔案不但定義了基本資料型別WORD，還包含了stdio.h syslib.h等等不常用的標頭檔案。如果工
程中有10000個原始檔，而其中100個原始檔使用了stdio.h的printf，由於上述標頭檔案的職責過於龐大，
而WORD又是每一個檔案必須包含的，從而導致stdio.h/syslib.h等可能被不必要的展開了9900次，大
大增加了工程的編譯時間。
原則1.3 標頭檔案應向穩定的方向包含。
說明： 標頭檔案的包含關係是一種依賴，一般來說，應當讓不穩定的模組依賴穩定的模組，從而當不穩
定的模組發生變化時，不會影響（編譯）穩定的模組。
就我們的產品來說，依賴的方向應該是： 產品依賴於平臺，平臺依賴於標準庫。 某產品線平臺的程式碼
中已經包含了產品的標頭檔案，導致平臺無法單獨編譯、釋出和測試， 是一個非常糟糕的反例。
除了不穩定的模組依賴於穩定的模組外，更好的方式是兩個模組共同依賴於介面，這樣任何一個模組
的內部實現更改都不需要重新編譯另外一個模組。在這裡，我們假設介面本身是最穩定的。
延伸閱讀材料： 編者推薦開發人員使用“依賴倒置”原則，即由使用者制定介面，服務提供者實現介面，
更具體的描述可以參見《敏捷軟體開發：原則、模式與實踐》 （Robert C.Martin 著 鄧輝 譯 清
華大學出版社2003年9月） 的第二部分“敏捷設計”章節。
規則1.1 每一個.c檔案應有一個同名.h檔案，用於宣告需要對外公開的介面。
說明： 如果一個.c檔案不需要對外公佈任何介面，則其就不應當存在，除非它是程式的入口，如main
函式所在的檔案。
現有某些產品中，習慣一個.c檔案對應兩個標頭檔案，一個用於存放對外公開的介面，一個用於存放內
部需要用到的定義、宣告等，以控制.c檔案的程式碼行數。編者不提倡這種風格。這種風格的根源在於
原始檔過大，應首先考慮拆分.c檔案，使之不至於太大。另外，一旦把私有定義、宣告放到獨立的頭
檔案中，就無法從技術上避免別人include之，難以保證這些定義最後真的只是私有的。
本規則反過來並不一定成立。有些特別簡單的標頭檔案，如命令ID定義標頭檔案，不需要有對應的.c存在。
示例：對於如下場景，如在一個.c中存在函式呼叫關係：
void foo()
{
bar();
}
void bar()
{
Do something;
}
必須在foo之前宣告bar，否則會導致編譯錯誤。
這一類的函式宣告，應當在.c的頭部宣告，並宣告為static的，如下：
static void bar();
void foo()
{
bar();
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第9頁,共61頁Page 9 , Total61
}
void bar()
{
Do something;
}
規則1.2 禁止標頭檔案迴圈依賴。
說明： 標頭檔案迴圈依賴，指a.h包含b.h， b.h包含c.h， c.h包含a.h之類導致任何一個頭檔案修改，都
導致所有包含了a.h/b.h/c.h的程式碼全部重新編譯一遍。而如果是單向依賴，如a.h包含b.h， b.h包含
c.h，而c.h不包含任何標頭檔案，則修改a.h不會導致包含了b.h/c.h的原始碼重新編譯。
規則1.3 .c/.h檔案禁止包含用不到的標頭檔案。
說明： 很多系統中標頭檔案包含關係複雜，開發人員為了省事起見，可能不會去一一鑽研，直接包含一
切想到的標頭檔案，甚至有些產品乾脆釋出了一個god.h，其中包含了所有標頭檔案，然後釋出給各個專案
組使用，這種只圖一時省事的做法，導致整個系統的編譯時間進一步惡化，並對後來人的維護造成了
巨大的麻煩。
規則1.4 標頭檔案應當自包含。
說明： 簡單的說，自包含就是任意一個頭檔案均可獨立編譯。 如果一個檔案包含某個標頭檔案，還要包
含另外一個頭檔案才能工作的話，就會增加交流障礙，給這個標頭檔案的使用者增添不必要的負擔。
示例：
如果a.h不是自包含的，需要包含b.h才能編譯，會帶來的危害：
每個使用a.h標頭檔案的.c檔案，為了讓引入的a.h的內容編譯通過，都要包含額外的標頭檔案b.h。
額外的標頭檔案b.h必須在a.h之前進行包含，這在包含順序上產生了依賴。
注意：該規則需要與“.c/.h檔案禁止包含用不到的標頭檔案”規則一起使用，不能為了讓a.h自包含，
而在a.h中包含不必要的標頭檔案。 a.h要剛剛可以自包含，不能在a.h中多包含任何滿足自包含之外的其
他標頭檔案。
規則1.5 總是編寫內部#include保護符（#define 保護） 。
說明：多次包含一個頭檔案可以通過認真的設計來避免。如果不能做到這一點，就需要採取阻止頭文
件內容被包含多於一次的機制。
通常的手段是為每個檔案配置一個巨集，當頭檔案第一次被包含時就定義這個巨集，並在標頭檔案被再次包
含時使用它以排除檔案內容。
所有標頭檔案都應當使用#define 防止標頭檔案被多重包含，命名格式為FILENAME_H，為了保證唯一性，
更好的命名是PROJECTNAME_PATH_FILENAME_H。
注：沒有在巨集最前面加上“_"，即使用FILENAME_H代替_FILENAME_H_，是因為一般以"_"和”__"開頭的
識別符號為系統保留或者標準庫使用，在有些靜態檢查工具中，若全域性可見的識別符號以"_"開頭會給出告
警。
定義包含保護符時，應該遵守如下規則：
1）保護符使用唯一名稱；
2）不要在受保護部分的前後放置程式碼或者註釋。
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第10頁,共61頁Page 10 , Total61
示例：假定VOS工程的timer模組的timer.h，其目錄為VOS/include/timer/timer.h,應按如下方式保護：
#ifndef VOS_INCLUDE_TIMER_TIMER_H
#define VOS_INCLUDE_TIMER_TIMER_H
...
#endif
也可以使用如下簡單方式保護:
#ifndef TIMER_H
#define TIMER_H
..
#endif
| #ifndef A_H__ #define A_H__ #ifdef __cplusplus void foo(int); #define a(value) foo(value) #else void a(int) #endif #endif /* A_H__ */ | #ifndef B_H__ #define B_H__ #ifdef __cplusplus extern "C" { #endif #include "a.h" void b(); #ifdef __cplusplus } #endif #endif /* B_H__ */ |
使用C++前處理器展開b.h，將會得到
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第11頁,共61頁Page 11 , Total61
extern "C" {
void foo(int);
void b();
}
按照a.h作者的本意，函式foo是一個C++自由函式，其連結規範為"C++"。但在b.h中，由於#include
"a.h"被放到了extern "C" { }的內部，函式foo的連結規範被不正確地更改了。
示例： 錯誤的使用方式：
extern “C”
{
#include “xxx.h”
...
}
正確的使用方式：
#include “xxx.h”
extern “C”
{
...
}
建議1.1 一個模組通常包含多個.c檔案，建議放在同一個目錄下，目錄名即為模組名。為方便外部使
用者，建議每一個模組提供一個.h，檔名為目錄名。
說明：需要注意的是，這個.h並不是簡單的包含所有內部的.h，它是為了模組使用者的方便，對外整
體提供的模組介面。
以Google test（簡稱GTest）為例， GTest作為一個整體對外提供C++單元測試框架，其1.5版本的gtest
工程下有6個原始檔和12個頭檔案。但是它對外只提供一個gtest.h，只要包含gtest.h即可使用GTest
提供的所有對外提供的功能，使用者不必關係GTest內部各個檔案的關係，即使以後GTest的內部實現
改變了，比如把一個原始檔c拆成兩個原始檔，使用者也不必關心，甚至如果對外功能不變，連重新編
譯都不需要。
對於有些模組，其內部功能相對鬆散，可能並不一定需要提供這個.h，而是直接提供各個子模組或者.c
的標頭檔案。
比如產品普遍使用的VOS，作為一個大模組，其內部有很多子模組，他們之間的關係相對比較鬆散，就
不適合提供一個vos.h。而VOS的子模組，如Memory（僅作舉例說明，與實際情況可能有所出入），其
內部實現高度內聚，雖然其內部實現可能有多個.c和.h，但是對外只需要提供一個Memory.h宣告介面。
建議1.2 如果一個模組包含多個子模組，則建議每一個子模組提供一個對外的.h，檔名為子模組名。
說明：降低介面使用者的編寫難度。
建議1.3 標頭檔案不要使用非習慣用法的副檔名，如.inc。
說明：目前很多產品中使用了.inc作為標頭檔案副檔名，這不符合c語言的習慣用法。在使用.inc作為頭
副檔名的產品，習慣上用於標識此標頭檔案為私有標頭檔案。但是從產品的實際程式碼來看，這一條並
沒有被遵守，一個.inc檔案被多個.c包含比比皆是。本規範不提倡將私有定義單獨放在標頭檔案中，具
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第12頁,共61頁Page 12 , Total61
體見 規則1.1。
除此之外，使用.inc還導致source insight、 Visual stduio等IDE工具無法識別其為標頭檔案，導致很
多功能不可用，如“跳轉到變數定義處”。雖然可以通過配置，強迫IDE識別.inc為標頭檔案，但是有些
軟體無法配置，如Visual Assist只能識別.h而無法通過配置識別.inc。
建議1.4 同一產品統一包含標頭檔案排列方式。
說明：常見的包含標頭檔案排列方式： 功能塊排序、檔名升序、穩定度排序。
示例1：
以升序方式排列標頭檔案可以避免標頭檔案被重複包含，如：
#include <a.h>
#include <b.h>
#include <c/d.h>
#include <c/e.h>
#include <f.h>
示例2：
以穩定度排序， 建議將不穩定的標頭檔案放在前面，如把產品的標頭檔案放在平臺的標頭檔案前面，如下：
#include <product.h>
#include <platform.h>
相對來說， product.h修改的較為頻繁，如果有錯誤，不必編譯platform.h就可以發現product.h的錯
誤，可以部分減少編譯時間。
2函式
背景
函式設計的精髓：編寫整潔函式，同時把程式碼有效組織起來。
整潔函式要求：程式碼簡單直接、不隱藏設計者的意圖、用乾淨利落的抽象和直截了當的控制語句將函
數有機組織起來。
程式碼的有效組織包括：邏輯層組織和物理層組織兩個方面。邏輯層，主要是把不同功能的函式通過某
種聯絡組織起來，主要關注模組間的介面，也就是模組的架構。物理層，無論使用什麼樣的目錄或者
名字空間等，需要把函式用一種標準的方法組織起來。例如：設計良好的目錄結構、函式名字、檔案
組織等，這樣可以方便查詢。
原則2.1 一個函式僅完成一件功能。
說明：一個函式實現多個功能給開發、使用、維護都帶來很大的困難。
將沒有關聯或者關聯很弱的語句放到同一函式中，會導致函式職責不明確，難以理解，難以測試和改
動。
案例： realloc。在標準C語言中， realloc是一個典型的不良設計。這個函式基本功能是重新分配記憶體，
但它承擔了太多的其他任務：如果傳入的指標引數為NULL就分配記憶體，如果傳入的大小引數為0就釋放
記憶體，如果可行則就地重新分配，如果不行則移到其他地方分配。如果沒有足夠可用的記憶體用來完成
重新分配（擴大原來的記憶體塊或者分配新的記憶體塊），則返回NULL，而原來的記憶體塊保持不變。這個
函式不易擴充套件，容易導致問題。例如下面程式碼容易導致記憶體洩漏：
char *buffer = (char *)malloc(XXX_SIZE);
.....
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第13頁,共61頁Page 13 , Total61
buffer = (char *)realloc(buffer, NEW_SIZE);
如果沒有足夠可用的記憶體用來完成重新分配，函式返回為NULL，導致buffer原來指向的記憶體被丟失。
延伸閱讀材料：《敏捷軟體開發：原則、模式與實踐》 第八章，單一職責原則(SRP)
原則2.2 重複程式碼應該儘可能提煉成函式。
說明：重複程式碼提煉成函式可以帶來維護成本的降低。
重複程式碼是我司不良程式碼最典型的特徵之一。在“程式碼能用就不改”的指導原則之下，大量的煙囪式
設計及其實現充斥著各產品程式碼之中。新需求增加帶來的程式碼拷貝和修改，隨著時間的遷移，產品中
堆砌著許多類似或者重複的程式碼。
專案組應當使用程式碼重複度檢查工具，在持續整合環境中持續檢查程式碼重複度指標變化趨勢，並對新
增重複程式碼及時重構。當一段程式碼重複兩次時，即應考慮消除重複，當代碼重複超過三次時，應當立
刻著手消除重複。
一般情況下，可以通過提煉函式的形式消除重複程式碼。
示例：
UC ccb_aoc_process( )
{
... ...
struct AOC_E1_E7 aoc_e1_e7;
aoc_e1_e7.aoc = 0;
aoc_e1_e7.e[0] = 0;
... ... //aoc_e1_e7.e[i]從到賦值，下同
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
... ...
if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
}
... ...
}
else if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第14頁,共61頁Page 14 , Total61
aoc_e1_e7.tariff_rate = 0;
}
ccb_caller_e1 = aoc_e1_e7.e[0];
... ...
ccb_caller_e7 = aoc_e1_e7.e[6];
ccb_caller_tariff_rate = aoc_e1_e7.tariff_rate;
... ...
}
... ...
if (xxx)
{
if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
}
... ...
}
else if (xxx)
{
if (xxx)
{
aoc_e1_e7.e[0] = 0;
... ...
aoc_e1_e7.e[6] = 0;
aoc_e1_e7.tariff_rate = 0;
}
ccb_caller_e1 = aoc_e1_e7.e[0];
... ...
ccb_caller_e7 = aoc_e1_e7.e[6];
ccb_caller_tariff_rate = aoc_e1_e7.tariff_rate;
... ...
}
return 1;
}
else
{
return 0;
密級： confidentiality level
DKBA 2826-2011.5
2011-06-02 華為機密，未經許可不得擴散 Huawei Confidential 第15頁,共61頁Page 15 , Total61
}
}
刺鼻的程式碼壞味充斥著這個函式。紅色字型的部分是簡單的程式碼重複，粗體字部分是程式碼結構的重複，
將重複部分提煉成一個函式即可消除重複。
規則2.1 避免函式過長，新增函式不超過50行（非空非註釋行） 。
說明：本規則僅對新增函式做要求，對已有函式修改時，建議不增加程式碼行。
過長的函式往往意味著函式功能不單一，過於複雜（參見原則2.1：一個函式只完成一個功能）。
函式的有效程式碼行數，即NBNC（非空非註釋行）應當在[1， 50]區間。
例外：某些實現演算法的函式，由於演算法的聚合性與功能的全面性，可能會超過50行。
延伸閱讀材料： 業界普遍認為一個函式的程式碼行不要超過一個螢幕，避免來回翻頁影響閱讀；一般的
程式碼度量工具建議都對此進行檢查，例如Logiscope的函式度量： "Number of Statement" （函式中的
可執行語句數）建議不超過20行， QA C建議一個函式中的所有行數（包括註釋和空白行）不超過50行。
規則2.2 避免函式的程式碼塊巢狀過深，新增函式的程式碼塊巢狀不超過4層。
說明：本規則僅對新增函式做要求，對已有的程式碼建議不增加巢狀層次。
函式的程式碼塊巢狀深度指的是函式中的程式碼控制塊（例如： if、 for、 while、 switch等）之間互相包
含的深度。每級巢狀都會增加閱讀程式碼時的腦力消耗，因為需要在腦子裡維護一個“棧”（比如，進
入條件語句、 進入迴圈„„）。應該做進一步的功能分解，從而避免使程式碼的閱讀者一次記住太多的
上下文。優秀程式碼參考值： [1, 4]。
示例：如下程式碼巢狀深度為5。
void serial (void)
{
if (!Received)
{
TmoCount = 0;
switch
相關推薦
C規範【學習用】
華為技術有限公司內部技術規範C語言程式設計規範華為技術有限公司Huawei Technologies Co., Ltd.修訂宣告Revision declaration本規範擬製與解釋部門：本規範的相關係列規範或檔案：相關國際規範或檔案一致性：替代或作廢的其它規範或檔案：相關
php函數源代碼 C編寫 【持續更新】
字符串 itl 自動 code strcpy return div 取字符 pau strlen（） 獲取字符串長度,成功則返回字符串 string 的長度；如果 string 為空，則返回 0。 #include<stdio.h> #include<s
C#精髓【月兒原創】第三講 C#泛型有什麼好處
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！
C#(四)-【多型】
概述 多型的字面意思是“多種狀態”，多型是面向物件三大特性之一，它是指同一個實體同時具有多種形式。如果一個語言只支援類而不支援多型，只能說明它是基於物件的，而不是面向物件的。 功能 1.多型——隱藏基類方法與多型的實現。 ——子類可以有與父類方法名相同的方法。 ——子類可以重寫父
C 精髓【月兒原創】第三講 C 泛型有什麼好處
說明：準備出一個系列，所謂精髓講C#語言要點。這個系列沒有先後順序，不過儘量做到精。可能會不斷增刪整理，本系列最原始出處是csdn部落格,謝謝關注。 C#精髓 第三講 C#泛型有什麼好處 作者：清清月兒 主頁：http://blog.csdn.net/21aspnet/ &n
C 精髓【月兒原創】第二講 WMI完美秀出CPU編號廠商主頻百分比等全部資訊
說明：準備出一個系列，所謂精髓講C#語言要點。這個系列沒有先後順序，不過儘量做到精。可能會不斷增刪整理，本系列最原始出處是csdn部落格,謝謝關注。C#精髓第二講 WMI完美秀出CPU編號廠商主頻電壓等全部資訊作者：清清月兒 關於WMI MSDN有詳細說明。 本文列舉數例算拋磚
codeforces #503 div 2 C Elections 【貪心+列舉】
題意： n個選民有對應的賄賂價格，最小要花費多少錢才能讓 編號1的選票是最多的； 思路： 貪心應該是比較容易想到的，但是如何列舉才能求出正確答案；這裡不是說把沒選編號1的選民都按照花費從小到大排序，然後從小到大依次加起來就完事了，我們還有一些特殊情況需要考慮的；比如
開啟C語言【困難模式】（1）
前言 談到C語言，很多人都會笑笑，好像C語言看起來很平凡，很普通，很大眾。然而值得注意的是，這是一門極其底層的語言，可以直接調用匯編語句，使用系統函式。不論是系統開發，驅動開發，作業系統還是緩衝區溢位攻擊等，C語言永遠是理解萬物的基石。 說來慚愧，博主此刻距離C語言的第一堂課已兩年有餘，
C-COT 【目標跟蹤】個人理解
該文章的主要思想是將傳統手工特徵換成了 vgg的特徵但是由於特徵層的解析度不同，故通過插值將每層特徵轉到 【0，T) 空間，公式如下其中 xd是d層特徵，Nd為每層的特徵行列數，bd為事先計算的權重，插值可以將特徵點精確到亞畫素級別隨後將各個特徵圖和濾波器進行卷起操作，類似於
C#梳理【集合Collection】
C# 集合（Collection） 集合（Collection）類是專門用於資料儲存和檢索的類。這些類提供了對棧（stack）、佇列（queue）、列表（list）和雜湊表（hash table）的支援。大多數集合類實現了相同的介面。 集合（Collection）
C#學習 【HttpClient學習】
簡單的說幾句：由於之前一直做的是PC端的APP，沒有做過WEB方面的專案，一直對類似搶票軟體這樣的程式很感興趣，很想弄一款搶手機啊，秒殺啊的APP出來。之前做過一個類似按鍵精靈功能的APP，就是不停的模擬滑鼠點選網頁中的按鈕。什麼時候能夠模擬瀏覽器來發送請求呢，
【學渣】字元匹配之有限狀態自動機--應用在爬蟲程式中匹配網址
關於自動機的原理的文章已經有很多了，我就不再多說了，我覺得很多部落格都寫的很好 我就寫一下在網址匹配方面的應用吧 其實很多人大都會選擇正則表示式 如果是有規律的匹配，應該有一個狀態轉移函式，但是我沒有為下圖找到規律，所以就用了最蠢的方法 如果是連續的輸入，比如ababab
從壹開始【學程式碼】|| 我開發中的用到的幾個框架
大家好，我是老張的哲學，下週要放假了，加班了好幾天，突然閒了一會兒，整理下我的Github，沒想到，這一年我已經提交了32個專案了，當然還有幾個不是開源的，突發奇想，給大家列出來，春節可以簡單翻開看看，俗話說：三人行，必有我師，擇其善者而從之，其不善者而改之。 一
【安全開發】C/C++安全編碼規範
C本質上是不安全的程式語言。例如如果不謹慎使用的話，其大多數標準的字串庫函式有可能被用來進行緩衝區攻擊或者格式字串攻擊。但是，由於其靈活性、快速和相對容易掌握，它是一個廣泛使用的程式語言。下面是針對開發安全的C語言程式的一些規範。 1.1.1 緩衝
【北風課堂】北風課堂http://ed免費學開發，分享了500多門免費課程，全部免費，java .net android php hadoop c++，嵌入式，遊戲開發等各種免費課程，有相關需要的可以去下載看看！
北風課堂 北風課堂http://ed免費學開發，分享了500多門免費課程，全部免費，java .net android php hadoop c++，嵌入式，遊戲開發等各種免費課程，有相關需要的可以去下載看看！...
【資訊學奧賽】【C++】（一）賦值語句
一、基本知識 在C/C++中，“=” 在語言中的作用並非是數學意義上的“等於號”，也不表示判斷。 “=”在這裡的意思是賦值：表示把它右邊的值賦給左邊。 一般形式為：變數=表示式 有的時候編譯器會提示不
74. Spring Data JPA方法定義規範【從零開始學Spring Boot】
【從零開始學習Spirng Boot—常見異常彙總】 事情的起因：有人問過我們這個這個問題：為什麼我利用Spring data jpa寫的方法沒有按照我想要的情況進行執行呢？我記得當時只是告訴他你你先看看Spring Data的命名規則吧。所以在這一小節把Spr
【C#程式設計最佳實踐 七】程式碼書寫規範實踐
以下規範都是個人書寫習慣，便於閱讀總結的個人規範，對於每個人可以有自己的理解。終極目標就是消除警告呀哈哈。 佈局規範 對於專案的總體規範，建議分為以下幾部分：1，對外提供服務的檔案。2，配置檔案和配置檔案解析類（如果有）。3，介面資料夾（介面和實現類）。4單
【BZOJ1935/4822】[Shoi2007]Tree 園丁的煩惱/[Cqoi2017]老C的任務 樹狀數組
tchar get ont n+1 div 區域 spa 都是 struct 題意：兩道題差不多，都是給你一堆平面上的點，每個點有權值，然後m次詢問求某一矩形區域內的點權和 題解：先離散化，然後將詢問拆成左右兩條線段，然後將點和這些線段一起按x坐標排序，在y軸上維護樹狀數
【動態規劃】 Codeforces Round #416 (Div. 2) C. Vladik and Memorable Trip
and main spa def esp 動態 return 價值 can 劃分那個序列，沒必要完全覆蓋原序列。對於劃分出來的每個序列，對於某個值v，要麽全都在該序列，要麽全都不在該序列。 一個序列的價值是所有不同的值的異或和。整個的價值是所有劃分出來的序列的價值之和。