c的編程規則
C語言代碼規范（編程規范）
什麼叫規范？在C語言中不遵守編譯器的規定，編譯器在編譯時就會報錯，這個規定叫作規則。但是有一種規定，它是一種人為的、約定成俗的，即使不按照那種規定也不會出錯，這種規定就叫作規范。
雖然我們不按照規范也不會出錯，但是那樣代碼寫得就會很亂。大家剛開始學習C語言的時候，第一步不是說要把程序寫正確，而是要寫規范。因為如果你養成一種非常不好的寫代碼的習慣，代碼就會寫得亂七八糟，等到將來工作面試的時候，這樣的習慣可能會讓你失去機會。
代碼如何寫才能規范
那麼代碼如何寫才能寫得很規范呢？代碼的規范化不是說看完本節內容後就能實現的。它裡面細節很多，而且需要不停地寫代碼練習，不停地領悟，慢慢地才能掌握的一種編程習慣。所以大家不要想著一下子就能把代碼規范化的所有知識全部掌握，也不要想著一下子就能把代碼寫規范，這是不太可能的。
有很多知識，比如為什麼代碼要這樣寫，為什麼不能那樣寫，作為一個初學者你是很難弄明白的。有很多規范是為了在程序代碼量很大的時候，便於自己閱讀，也便於別人閱讀。
所以剛開始的時候有很多規范你不知道為什麼要那樣規定，你就單純地模仿就行了。等將來敲代碼敲得時間長了，你就會感覺到那樣寫是很有好處的。
代碼規范化的好處
代碼規范化的第一個好處就是看著很整齊、很舒服。假如你現在用不規范的方式寫了一萬行代碼，現在能看得懂，但等過了三個月你再回頭看時就很吃力了，更不要說給別人看了。所以代碼要寫規范，比如加註釋就是代碼規范化的一個思想。
在一般情況下，根據軟體工程的思想，我們的注釋要佔整個文檔的20%以上。所以注釋要寫得很詳細，而且格式要寫得很規范。
第二個好處是，把代碼寫規范則程序不容易出錯。如果按照不規范的格式輸入代碼的話，很容易出錯。而代碼寫規范的話即使出錯了查錯也會很方便。格式雖然不會影響程序的功能，但會影響可讀性。程序的格式追求清晰、美觀，是程序風格的重要構成元素。
代碼規范化的七大原則
代碼規范化基本上有七大原則，體現在空行、空格、成對書寫、縮進、對齊、代碼行、注釋七方面的書寫規范上。
1) 空行
空行起著分隔程序段落的作用。空行得體將使程序的布局更加清晰。空行不會浪費內存，雖然列印含有空行的程序會多消耗一些紙張，但是值得。
規則一：定義變數後要空行。盡可能在定義變數的同時初始化該變數，即遵循就近原則。如果變數的引用和定義相隔比較遠，那麼變數的初始化就很容易被忘記。若引用了未被初始化的變數，就會導致程序出錯。
規則二：每個函數定義結束之後都要加空行。
總規則：兩個相對獨立的程序塊、變數說明之後必須要加空行。比如上面幾行代碼完成的是一個功能，下面幾行代碼完成的是另一個功能，那麼它們中間就要加空行。這樣看起來更清晰
B. C語言的書寫規則主要有哪些呢
1.
1.1符號命名規則
1.1.1符號名包括模塊名、常量名、標號名、子程序名等。這些名字應該能反映它所代表的實際東西，具有一定的意義，使其能夠見名知義，有助於對程序功能的理解。命名採用匈牙利命名法。規則如下：
(1)所有宏定義、枚舉常數和const變數，用大寫字母命名。在復合詞里用下劃線隔開每個詞。
(2)復合詞中每個單詞的第一個字母大寫。除了規則5.1.1.1以外，避免使用下劃線。
(3)類、類型定義和枚舉型名的第一個字母大寫。
(4)函數名是復合詞的，第一個詞採用全部小寫，隨後每個單詞採用第一個字母大寫，其它字母小寫方式；如果是單個詞的，採用全部小寫方式。
(5)循環變數可採用i, j, k等，不受上述規則限制。
(6) 類的成員變數應採用m_開頭。
(7) 全局變數詞頭為g_ 。
(8) 臨時變數詞頭為tmp_ 。
(9) 對結構體內的變數命名, 遵循變數的具體含義命名原則
(10)用小寫字母的前綴表示變數的類型，前綴的下一個字母用大寫。
表 1
詞頭 類型 詞頭 類型
ch char l long
i integer u unsigned
b boolean p pointer
f float lp long pointer
d double s string
st structure sz ASCII string
by byte n short int
H handle x,y 分別為x,y坐標
dw DWORD fn function
表 2
詞頭 變數名 詞頭 變數名
task task sig signal
sb binary semaphores wd watchdog
sm mutual exclusion tm timer
sc counting semaphores msg message
pipe pipe
例：
#define ARRAY_SIZE 24 /*規則5.1.1.1*/
int g_iFlag;
class MyClass /*規則5.1.1.3*/
{
};
void someFunc( ) /*規則5.1.1.2和5.1.1.4*/
{
int nArray[ARRAY_SIZE];
unsigned char uchByte;
char szName[ ];
char *pszName = szName;
}
(11)有些詞頭（如p和u）可以和其它詞頭組合。
例：WDOG_ID wdId;
WDOG_ID g_wdId; /*全局watchdog Id，故以g_開頭*/
1.1.2名字的長度一般不要過長或過短。過長的名字會增加工作量，使程序邏輯流程變得模糊；過短的名字無法表達符號的實際意義。約定長度范圍：3-31；
1.2數據和函數說明
1.2.1數據說明次序應當規范化，使數據屬性容易查找，也有利於測試、排錯和維護。說明的先後次序應固定，應按邏輯功能排序，邏輯功能塊內建議採用下列順序：整型說明、實型說明、字元說明、邏輯量說明。
1.2.2如果設計了一個復雜的數據結構，應當通過注釋對其變數的含義、用途進行說明。
1.2.3在函數的聲明中使用異常聲明。
如：void f() throw(toobig, toosmall, divzero);
在聲明一個函數時，將它所拋出的異常列出，便於函數的使用者了解可能會發生哪些異常。
1.3 程序注釋
1.3.1程序注釋是程序員與日後的程序讀者之間通信的重要手段之一，注釋分為文件注釋、函數注釋和功能注釋。
1.3.2正規程序的注釋應注意：
——注釋行的數量佔到整個源程序的1/3到1/2。
1.3.3文件注釋位於整個源程序的最開始部分，注釋後空兩行開始程序正文。它包括：
——程序標題。
——目的、功能說明。
——文件作者、最後修改日期等說明。
例：
./********************************************************************
（空一行）
標題: Demo.c
功能: 測試VxWorks的各種系統調用.
說明:
該程序測試各種VxWorks的系統調用函數。包括任務（taks）的創建、掛起及任務間通過信號燈實現同步，通過消息隊列 進行通訊。
程序創建了兩個任務：一個高優先順序的任務和一個低優先順序的任務。兩個任務間通過一個二進制的信號燈進行同步，通過消息隊列進行通訊。
當前版本： x.x
修改信息： 2000.06.05 John， Initial Version
2000.07.05 Tom， Bug xxxx fixed
**************************************************************/
(空2行，開始程序正文)
1.3.4 函數注釋通常置於每函數或過程的開頭部分，它應當給出函數或過程的整體說明對於理解程序本身具有引導作用。一般包括如下條目：
——模塊標題。
——有關本模塊功能和目的的說明。
——調用格式
——介面說明：包括輸入、輸出、返回值、異常。
——演算法。如果模塊中採用了一些復雜的演算法。
例：
file://（/注釋開頭應和上一函數空兩行）
（注釋開頭與上一函數最後一行間隔兩行）
/********************************************************************
標題：assignmentComplete
功能：BSC=>MSC消息生成函數，生成assignment_complete指配完成消息(BSMAP消息) .
格式：
int assignmentComplete(int iCellId, int iServiceChannnelNum, char *pszMSGData) throw(exception1, exception2)
輸入：
int iCellId: MS所在的小區識別
iCellId取值：0x00-——0xff
int iServiceChannnelNum：MS所佔的業務信道號碼
輸出：
char * pszMSGData：指配完成消息數據
返回值: 0x00正常
異常：exception1異常情況1, exception2異常情況2
********************************************************************/
( 注釋後直接開始程序正文，不空行。)
1.3.5功能性注釋嵌在源程序體中，用於描述其後的語句或程序段做什麼工作，也就是解釋下面要做什麼，或是執行了下面的語句會怎麼樣。而不要解釋下面怎麼做，因為解釋怎麼做常常與程序本身是重復的。
例：
/*把 amount 加到 total中*/
total = amount + total;
這樣的注釋僅僅是重復了下面的程序，對於理解它的工作並沒有什麼作用。而下面的注釋，有助於讀者理解。
/*將每月的銷售額amount加到年銷售額total中*/
total = amount + total;
1.4 函數編寫應盡可能短小精悍，一般不超過兩屏，以便於調試和理解。
1.5語句結構
為保證語句結構的清晰和程序的可讀性，在編寫軟體程序時應注意以下幾個方面的問題：
——在一行內只寫一條語句，並採用空格、空行和移行保證清楚的視覺效果。
——每一個嵌套的函數塊，使用一個TAB縮進（可以設定為4個空格），大括弧必須放在條件語句的下一行，單獨成一行，便於匹對：
如，有一段程序如下：
for(i=1;i<n-1;i++){ t=1; for(j=i+1;j<n;j++){
if(a[j]<a[t] ) t=j; if(t!=i ){work=a[t];a[t]=a[I];a[I]=work;}}}
應寫為
for( i=1; i<n-1; i++)
{
t=1;
for(j = i+1; j<n; j++)
{
if(a[i]<a[j])
t=j;
if(t!=1)
{ .5.
Q/ECC/BJ 010—2001
work=a[t];
a[t]=a[i];
a[i]=work;
}
}
}
——文件之中不得存在無規則的空行，比如說連續十個空行。
一般來講函數與函數之間的空行為2-3行；
在函數體內部，在邏輯上獨立的兩個函數塊可適當空行，一般為1-2行。
——程序編寫首先應考慮清晰性，不要刻意追求技巧性而使得程序難以理解。
——每行長度盡量避免超過屏幕寬度，應不超過80個字元。
——除非對效率有特殊要求，編寫程序要作到清晰第一，效率第二。
——盡可能使用函數庫。
——盡量用公共過程或子程序去代替重復的功能代碼段。要注意，這個代碼應具有一個獨立的功能，不要只因代碼形式一樣便將其抽出組成一個公共過程或子程序。
——使用括弧清晰地表達算術表達式和邏輯表達式的運算順序。如將 x=a*b/c*d 寫成 x=(a*b/c)*d可避免閱讀者誤解為x=(a*b)/(c*d)。
——避免不必要的轉移。
——避免採用過於復雜的條件測試。
——避免過多的循環嵌套和條件嵌套。
——建議不要使用 *=，^=, /=等運算符。
——一個函數不要超過200行。一個文件應避免超過2000行。
——盡量避免使用go to語句。
——避免採用多賦值語句，如x = y = z ;
——不鼓勵採用?:操作符，如z = (a>b)?a:b;
——不要使用空的if else 語句。如
if(cMychar >= 『A』)
if(cMychar <= 『Z』)
printf(「This is a letter \n」);
else
printf(「This is not a letter \n」);
else到底是否定哪個if容易引起誤解。可通過加{}避免誤解。
——盡量減少使用「否定」條件的條件語句。如：
把 if( !( (cMychar<』0』) || (cMychar>』9』) ) )
改為if( (cMychar>=』0』) && (cMychar<=』9』)
C. C語言的書寫規則主要有哪些呢
從書寫清晰，便於閱讀，理解，維護的角度出發，在書寫程序時
應遵循以下規則:
1.一個說明或一個語句佔一行。
2.用{}
括起來的部分，通常表示了程序的某一層次結構。{}一般與該結構語句的第一個字母對齊，並單獨佔一行。
3.低一層次的語句或說明可比高一層次的語句或說明縮進若干格後書寫。以便看起來更加清晰，增加程序的可讀性。在編程時應力求遵循這些規則，以養成良好的編程風格。
有空格的地方就可以換行!
if(
a
==
b
&&
e
==
c
){}
和
if(
a
==
b
&&
e
==
c
)
{
}
是完全一樣的
D. 用C語言編程中,一般的格式是怎樣的
用C語言編程中,一般的格式是怎樣的。
你的問題問得不是很清晰，你具體是在說什麼格式呢？C語言的文件格式其實就是.C啊，如果是編譯過後的，一般就是.obj 或者.exe 或者 .dll 等等。
C語言還有個文件格式是.h。這個是頭文件。
E. c語言如何編程
C語言編程如何快速實現
在我們初次學習C語言的時候，總想著快速的實現編譯過程。那麼C語言編程究竟是如何實現的呢，當然是要通過自己喜歡的編譯器來編譯完成，那麼今天就為大家介紹C語言編程是如何快速的實現。
1. 首先我們下載一款適合C語言的編譯器，今天為大家講解的C語言編譯器為CodeBlocks，該編譯器沒有太過復雜，很符合初學者，簡單上手快。
F. C語言編寫程序四則運演算法則
1234567891011121314151617# include <stdio.h>int main(void){ int a,b,s; char c; scanf("%d%c%d",&a,&c,&b); switch(c) { case '+':s=a+b;break; case '-':s=a-b;break; case '*':s=a*b;break; case '/':s=a/b;break; default:return -1; } printf("%d",s); return 0;}
如果還要判斷除數為0的情況 再添個if即可
G. 有誰知道C語言程序的編程規范，給我概括一下，
1引言
1.1編寫目的
在軟體開發過程中，編碼的工作量是相當大的，同一項目參與編程的人可能有各自編程的經驗和習慣，不同風格的程序代碼使維護工作變得復雜和困難。為了提高代碼的可讀性、系統的穩定性及降低維護和升級的成本，特編寫本規范以統一各開發人員的編程工作。
1.2 適用對象
本規范適用於所有開發人員，包括應用程序、網頁及資料庫開發人員，及有關的程序測試人員。
1.3 引用標准
GB/T 11457 軟體工程術語
GB 8566 計算機軟體開發規范
GB 8567 計算機軟體產品開發文件編制指南
2．編寫要求
2.1一般代碼規則
可讀性原則，這是評價程序質量的首選指標，寧可不要一些技巧也要保證程序的易讀特性，不要因過分追求技巧而犧牲程序的可讀性。
功能獨立性原則。每一程序塊只完成一個獨立的功能，反過來，每一獨立的功能只在一程序塊內完成，盡量低耦合、高內聚。
提示說明應當簡短且避免產生歧義。
提示或警告信息應當具有向導性，能准確告訴用戶錯誤原因及恢復方法。提示和警告對話框應當使用標准規范。
快捷鍵的定義必須符合用戶操作習慣。
程序需要長時間處理或等待時，應當顯示進度條並提示用戶等待。
一些敏感操作，如刪除等操作在執行前必須提示用戶確認。
2.2變數、函數、過程、控制項等命名規則
2.2.1 變數命名
變數命名採用[作用范圍][數據類型][自定義名稱]規則定義，並遵循匈牙利命名法。要求看到變數名就能直觀的看出其范圍和數據類型。
匈牙利命名規則：
a Array 數組
b BOOL (int) 布爾(整數)
by Unsigned Char (Byte) 無符號字元(位元組)
c Char 字元(位元組)
cb Count of bytes 位元組數
cr Color reference value 顏色(參考)值
cx Count of x (Short) x的集合(短整數)
dw DWORD (unsigned long) 雙字(無符號長整數)
f Flags (usually multiple bit values) 標志(一般是有多位的數值)
fn Function 函數
g_ global 全局的
h Handle 句柄
i Integer 整數
l Long 長整數
lp Long pointer 長指針
m_ Data member of a class 一個類的數據成員
n Short int 短整數
p Pointer 指針
s String 字元串
sz Zero terminated String 以0結尾的字元串
tm Text metric 文本規則
u Unsigned int 無符號整數
ul Unsigned long (ULONG) 無符號長整數
w WORD (unsigned short) 無符號短整數
x,y x, y coordinates (short) 坐標值/短整數
v void 空
作用范圍：
范圍 前綴 例子
全局作用域 g_ g_Servers
成員變數 m_ m_pDoc
局部作用域 無 strName
數據類型
VC常用前綴列表
前綴 類型 描述 例子
ch char 8位字元 chGrade
ch TCHAR 16位UNICODE類型字元 chName
b BOOL 布爾變數 bEnabled
n int 整型（其大小由操作系統決定） nLength
n UINT 無符號整型（其大小由操作系統決定） nLength
w WORD 16位無符號整型 wPos
l LONG 32位有符號整型 lOffset
dw DWORD 32位無符號整型 dwRange
p * 內存模塊指針，指針變數 pDoc
l p FAR* 長指針 lpDoc
lpsz LPSTR 32位字元串指針 lpszName
lpsz LPCSTR 32位常量字元串指針 lpszName
lpsz LPCTSTR 32位UNICODE類型常量指針 lpszName
h handle Windows對象句柄 hWnd
lpfn (*fn)() 回調函數指針 Callback Far pointer to
CALLBACK function lpfnAbort
2.2.2 函數、過程命名
函數或過程名的主體應該使用大小寫混合形式，並且應該足夠長以描述它的作用。而且，函數名應該以一個動詞起首，如 InitNameArray 或 CloseDialog。對於頻繁使用的或長的項，推薦使用標准縮略語以使名稱的長度合理化。一般來說，超過 32 個字元的變數名在 VGA 顯示器上讀起來就困難了。當使用縮略語時，要確保它們在整個應用程序中的一致性。在一個工程中，如果一會兒使用 Cnt， 一會兒使用 Count，將導致不必要的混淆。
對於自行編寫的函數，若是系統關鍵函數，則須在函數實現部分的上方標明該函數的信息，格式如下：
//======================================================
// 函 數 名：InsureHasOutputInfo
// 功能描述：確保有適當的輸出信息
// 輸入參數：nProctID:相應的產品ID
// 輸出參數：void
// 創建日期：00-2-21
// 修改日期：00-2-21
// 作 者：***
// 附加說明：
//======================================================
2.2.3 用戶定義類型
在一項有許多用戶定義類型的大工程中，常常有必要給每種類型一個它自己的三個字元的前綴。如果這些前綴是以 "u" 開始的，那麼當用一個用戶定義類型來工作時，快速識別這些類型是很容易的。例如，ucli 可以被用來作為一個用戶定義的客戶類型變數的前綴。
註：對於非通用的變數，請在定義時加以注釋說明，變數定義盡可能放在最開始處。
2.2.4 控制項命名
應該用一致的前綴來命名對象，使人們容易識別對象的類型。
VC常用宏定義命名列表
前綴 符號類型 符號例子 范圍
IDR_ 標識多個資源共享的類型 IDR_MAINFRAME 1~0x6FFF
IDD_ 對話框資源（Dialog） IDD_SPELL_CHECK 1~ 0x6FFF
HIDD_ 基於對話框的上下文幫助 HIDD_SPELL_CHECK 0x20001~0x26FF
IDB_ 點陣圖資源（Bitmap） IDB_COMPANY_LOGO 1~0x6FFF
IDC_ 游標資源（Cursor） IDC_PENCIL 1~0x6FFF
IDI_ 圖標資源（Icon） IDI_NOTEPAD 1~0x6FFF
ID_、IDM_ 工具欄或菜單欄的命令項 ID_TOOLS_SPELLING 0x8000~0xDFFF
HID_ 命令上下文幫助 HID_TOOLS_SPELLING 0x18000~0x1DFFF
IDP_ 消息框提示文字資源 IDP_INVALID_PARTNO 8~0xDFFF
HIDP_ 消息框上下文幫助 HIDP_INVALID_PARTNO 0x30008~0x3DFFF
IDS_ 字元串資源（String） IDS_COPYRIGHT 1~0x7FFF
IDC_ 對話框內的控制資源 IDC_RECALC 8~0xDFFF
2.3源代碼規則
2.3.1風格約定：採用縮進的格式保存程序的層次結構。要求能直觀的看出循環、判斷等層次結構。
每一個嵌套的函數塊，使用一個TAB縮進（可以設定為4個空格），大括弧必須放在條件語句的下一行，單獨成一行，便於匹對反大括弧應該在單獨的一行，在大多數情況下反擴號應有注釋內容。舉例如下：
if(condition1)
{
while(condition2)
{
…..
…..
}//end while(condition2)
}//end if (condition1)
或者
if(condition1){
while(condition2){
….
….
}//end while(condition2)
}//end if(conditionl)
2.3.2在操作符的前後必須使用空格。
2.3.3在分隔數組下標和函數參數的逗號後面必須添上空格。
2.3.4嚴禁使用go to 語句。
2.3.5對資料庫操作只能使用標准SQL語句，關鍵字必須使用大寫（如SELECT、WHERE等），數據元素（表、欄位、視圖等）必須按照數據字典書寫。
2.3.6程序代碼中要有足夠的容錯處理功能。
對可能發生的異常統一採用C++拋出格式：
try
{
//可能引發異常的代碼
throw t; //手工拋出異常
}
catch(type_1 e) // type_1為類型定義符、如int、CException、_com_error
{
// type_1類型異常處理
}
catch(type_2 e)
{
// type_2類型異常處理
}
2.3.7程序代碼結構必須層次清楚，適當使用空行分段。
2.3.8工程的版本控制要嚴格，版本格式為.me.ae.yy.mmdd，其中：[me]表示主版本號；[ae]表示輔版本號；[yy.mmdd]表示版本建立日期。高版本盡量兼容低版本的用法、數據或協議。
2．4文件的命名規則
2.4.1根據系統設計所規定的結構，建立相應的文件夾，根據需要建立子文件夾。
2.4.2文件夾和文件的名稱應盡量能夠表達其意義，盡量使用英文命名，絕對不能漢字。
2.4.3文件名稱一般採用「xxx_yyy.ext」格式，xxx(3-4個字母)表示分類，yyy(字母數自定)表示操作 (如 「 /example/exp_edit.htm 」)
\
我從公司文檔拷貝的！你自己看看對你有沒有用！
H. 用C語言編程中,一般的格式是怎樣的
C語言源程序的編程格式歸納如下: 1,強制性規則 1,一個C語言源程序必須有且只有一個MAIN函數. 2,函數名後必須緊跟圓括弧對,函數體放在右圓括弧")"後的花括弧對"{}"中. 3,每個程序體(包括函數的函數體,含有多條語句的選擇結構和循環結構中的語句序列)必須用一對花括弧括起來. 4,文件包含預處理命令,#INCLUDE<*.H>應置於源程序的開始位置. 5,語句未尾必須有分號,而預處理命令和函數首部的未尾及右花括弧之後不要分號. 6,同一字母大,小寫意義不同,關鍵字和標准庫函數名必須用小寫. 7,變數必須先定義,後使用 8,除已有明顯間隔符外,標識符,關鍵字之間必須有至少一個空格 9,註解必須包含在"/* */符號之間 我想你想要知道的是C語言的四種程序結構吧 如下：1，分支語句格式 ①if(條件) {分支體} 這種分支結構中的分支體可以是一條語句，此時「{}」可以省略，也可以是多條語句即復合語句。它有兩條分支路徑可選，一是當條件為真，執行分支體，否則跳過分支體，這時分支體就不會執行。如：要計算x的絕對值，根據絕對值定義，我們知道，當x>=0時，其絕對值不變，而x<0時其絕對值是為x的反號，因此程序段為：if(x<0)x=-x; ②if(條件) {分支1} else {分支2} ③IF嵌套分支語句：其語句格式為： if(條件1) {分支1} else if（條件2） {分支2} else if（條件3） {分支3} …… else if（條件n） {分支n} else {分支n+1} FOR嵌套，其語句格式為： for(初值A；范圍A；步長A) { for(初值B；范圍B；步長B） { 循環體 } } FOR嵌套例子：九九乘法表 main()這里是主程序的編程格式，你參考下 { int a,b,c; for(a=1;a<=9;a++) { for(b=1;b<=a;b++) { c=b*a; printf("%dx%d=%d ",b,a,c); } printf("\n"); } }
採納哦
I. 華為c語言編程規范是怎樣的
代碼總體原則
清晰第一。清晰性是易於維護、易於重構的程序必須具備的特徵。
簡潔為美。簡介就是易於理解並且易於實現。
選擇合適的風格，與源代碼風格保持一致。
頭文件
頭文件的設計體現了大部分的系統設計，不合理的頭文件布局是編譯時間過長的根因，實際上是不合理的設計。
頭文件中適合放置介面的聲明，不適合放置實現。
頭文件應當職責單一。
頭文件應向穩定的方向包含。
每一個.c文件應有一個同名的.h文件，用於聲明需要對外公開的介面。
禁止頭文件循環依賴。
禁止包含用不到的頭文件。
頭文件應當自包含。
編寫內部#include保護符(#define保護)。
禁止在頭文件中定義變數。
只能通過包含頭文件的方式使用其他C提供的介面，禁止在C中通過extern的方式使用外部函數介面和變數。
禁止在extern "C"中包含頭文件。
函數
函數設計的精髓：編寫整潔函數，同事把代碼有效組織起來。
一個函數僅完成一個功能。
重復代碼應該盡可能提煉成函數。
避免函數過長，新增函數不超過50行。
避免函數的代碼塊嵌套過深，新增函數的代碼塊嵌套不超過4層。
可重入函數應避免使用共享變數；若需要使用，則應該通過互斥手段對其加以保護。
對參數的合法性檢查，由調用者負責還是介面函數負責，應在項目組模塊內統一規定。預設由調用者負責。
對函數的錯誤返回碼要全面處理。
設計高扇入，合理扇出（小於7）的函數。扇出是指調用其它函數的數目。扇入是指有多少上級函數調用它。
廢棄代碼要及時清除。
函數參數不變使用const限定。
函數應避免使用全局變數、靜態局部變數和I/O操作，不可避免的地方應集中使用。
檢查函數所有非參數輸入的有效性，如數據文件、公共變數等。
函數的參數個數不超過5個。
在源文件范圍內聲明和定義的所有函數，除非外部可見，否則應該加static關鍵字。
標識符
標識符的命名要清晰、明了，有明確含義，同時使用完整的單詞或大家基本可以理解的縮寫，避免使人產生誤解。
產品、項目組內應保持同意的命名分格。
盡量避免名字中出現數字編號，除非邏輯上確實需要。
重構、修改部分代碼時，應該保持和原有代碼風格一致。
文件命令統一採用小寫字元。因為不同系統對文件名大小寫處理會有不同（windows不區分大小寫，但是linux系統則區分）。
全局變數應增加「g_」前綴。
靜態變數應增加「s_」前綴。
禁止使用單位元組命名變數，但是允許定義i,j,k作為局部循環變數。
不建議使用匈牙利命名法。
對於數值或者字元串常量的定義，建議採用全大寫字母，單詞之間加下劃線的方式命名。
變數
結構功能單一，不要設計面面俱到的數據結構。
不用或者少用全局變數
防止局部變數與全局變數同名
通訊過程中使用的機構，必須注意位元組序。
嚴禁使用未經初始化的變數作為右值。
使用面向介面編程思想，通過API訪問數據。
盡量減少沒有必要的數據類型默認轉換與強制轉換。
宏和常量
用宏定義表達式時，要使用完備的括弧。
將宏定義的多條表達式放在大括弧中。
使用宏時，不允許參數發生變化。
不允許直接使用魔鬼數字。
除非必要，應盡可能使用函數代替宏。
常量建議用const定義代替宏。
質量
時刻注意易混淆的操作符
必須了解編譯系統的內存分配方式，特別是編譯系統對不同類型的變數的內存分配規則，如局部變數在何處分配、靜態變數在何處分配等。
不僅關注介面，同樣要關注實現。
禁止內存操作越界。
禁止內存泄漏。
禁止引用已經釋放的內存空間。
編程時，要防止差1錯誤。
switch語句必須有default分支。
函數中分配的內存，在函數退出之前要釋放。
不要濫用goto語句。
時刻注意表達式是否會上溢、下溢。
程序效率
在保證軟體系統的正確性、簡潔、可維護性、可靠性及可測試性的前提下，提高代碼的效率。
通過對數據結構、程序演算法的優化來提高效率。
將不變條件的計算移到循環體外。
對於多維大數組，避免來回跳躍式訪問數組成員。
創建資源庫，以減少分配對象的開銷。
將多次被調用的「小函數」改為inline函數或者宏實現。
注釋
優秀的代碼可以自我解釋，不通過注釋即可輕易讀懂。
注釋的內容要清楚、明了，含義准確，防止注釋二義性。
修改代碼時，維護代碼周邊的所有注釋，以保證注釋與代碼的一致性。不再有用的注釋要刪除。
文件頭部應進行注釋，注釋需要列出：版權說明、版本號、生成日期、作者姓名、工號、內容、功能說明、與其他文件的關系、修改日誌等，頭文件的注釋中還應有函數功能的說明。
函數聲明處注釋描述函數功能、性能及用法，包括輸入和輸出參數、函數返回值、可重入的要求等；定義處詳細描述函數功能和實現要點，如實現的簡要步驟、實現的理由、設計約束等。
全局變數要有詳細的注釋，包括對其功能、取值范圍以及存取時注意事項等的說明。
盡量採用工具可以識別的格式注釋。
排版與格式
程序塊採用縮進風格編寫，每級縮進為4個空格。
相對獨立的程序塊之間、變數說明之後必須加空行。
一行只寫一條語句。
對等操作兩邊加空格，注釋符與內容之間加空格。
編譯
使用編譯器的最高告警級別，理解所有的告警，通過修改代碼而不是降低告警級別來消除所有告警。
在產品軟體中，要統一編譯開關、靜態檢查選項以及相應告警清除策略。
可測性
模塊劃分清晰，介面明確，耦合性小，有明確輸入和輸出，否則單元測試實施困難。
在統一項目組或產品組內，調測列印的日誌要有統一的規定。
使用斷言記錄內部假設。
不能用斷言來檢查運行時錯誤。