1. 基本要求
1.1 程序結構清析，簡單易懂，單個函數的程序行數不得超過100行。
1.2 打算干什麼，要簡單，直接了當，代碼精簡，避免垃圾程序。
1.3 盡量使用標准庫函數和公共函數。
1.4 不要隨意定義全局變量，盡量使用局部變量。
1.5 使用括號以避免二義性。
2.可讀性要求
2.1 可讀性第一，效率第二。
2.2 保持注釋與代碼完全一致。
2.3 每個源程序文件，都有文件頭說明，說明規格見規范。
2.4 每個函數，都有函數頭說明，說明規格見規范。
2.5 主要變量（結構、聯合、類或對象）定義或引用時，注釋能反映其含義。
2.7 常量定義（DEFINE）有相應說明。
2.8 處理過程的每個階段都有相關注釋說明。
2.9 在典型算法前都有注釋。
2.10 利用縮進來顯示程序的邏輯結構，縮進量一致並以Tab鍵為單位，定義Tab為 6個
字節。
2.11 循環、分支層次不要超過五層。
2.12 注釋可以與語句在同一行，也可以在上行。
2.13 空行和空白字符也是一種特殊注釋。
2.14 一目了然的語句不加注釋。
2.15 注釋的作用范圍可以為：定義、引用、條件分支以及一段代碼。
2.16 注釋行數（不包括程序頭和函數頭說明部份）應占總行數的 1/5 到 1/3 。
3. 結構化要求
3.1 禁止出現兩條等價的支路。
3.2 禁止GOTO語句。
3.3 用 IF 語句來強調只執行兩組語句中的一組。禁止 ELSE GOTO 和 ELSE RETURN。
3.4 用 CASE 實現多路分支。
3.5 避免從循環引出多個出口。
3.6 函數只有一個出口。
3.7 不使用條件賦值語句。
3.8 避免不必要的分支。
3.9 不要輕易用條件分支去替換邏輯表達式。
4. 正確性與容錯性要求
4.1 程序首先是正確，其次是優美
4.2 無法證明你的程序沒有錯誤，因此在編寫完一段程序後，應先回頭檢查。
4.3 改一個錯誤時可能產生新的錯誤，因此在修改前首先考慮對其它程序的影響。
4.4 所有變量在調用前必須被初始化。
4.5 對所有的用戶輸入，必須進行合法性檢查。
4.6 不要比較浮點數的相等，
如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7 程序與環境或狀態發生關系時，必須主動去處理發生的意外事件，如文件能否
邏輯鎖定、打印機是否聯機等。
4.8 單元測試也是編程的一部份，提交聯調測試的程序必須通過單元測試。
5. 可重用性要求
5.1 重復使用的完成相對獨立功能的算法或代碼應抽象為公共控件或類。
5.2 公共控件或類應考慮OO思想，減少外界聯系，考慮獨立性或封裝性。
5.3 公共控件或類應建立使用模板。
附：C＋＋ 編程規范,delphi作相應的參考
1適用范圍
本標准適用於利用Visul C++ ,Borland C++進行軟件程序開發的人員.。
.2變量命名
命名必須具有一定的實際意義,形式為xAbcFgh,x由變量類型確定,Abc、Fgh表示連續意
義字符串,如果連續意義字符串僅兩個,可都大寫.如OK.
具體例程:
BOOL類型 bEnable;
ch * char chText
c * 類對象 cMain（對象實例）
h * Handle（句柄） hWnd
i * int
n * 無符號整型
p * 指針
sz,str * 字符串
w WORD
x,y 坐標
Char或者TCHAR類型 與Windows API有直接聯系的用szAppName[10]形式否則用
FileName[10]形式,單個字符也可用小寫字母表示;
Int類型 nCmdShow;
LONG類型 lParam;
UINT類型 uNotify;
DWORD類型 dwStart;
PSTR類型 pszTip;
LPSTR類型 lpCmdLine
LPTSTR類型 lpszClassName;
LPVOID類型 lpReserved
WPARAM類型 wParam,
LPARAM類型 lParam
HWND類型 hDlg;
HDC類型 hDC;
HINSTANCE類型 hInstance
HANDLE類型 hInstance,
HICON類型 hIcon;
int iTmp
float fTmp
DWORD dw*
String , AnsiString str *
m_ 類成員變量 m_nVal, m_bFlag
g_ 全局變量 g_nMsg, g_bFlag
局部變量中可采用如下幾個通用變量：nTemp，nResult，I，J（一般用於循環變量）。
其他資源句柄同上
.3常量命名和宏定義
常量和宏定義必須具有一定的實際意義;
常量和宏定義在#include和函數定義之間;
常量和宏定義必須全部以大寫字母來撰寫,中間可根據意義的連續性用下劃線連接,每一
條定義的右側必須有一簡單的注釋,說明其作用;
資源名字定義格式:
菜單:IDM_XX或者CM_XX
位圖:IDB_XX
對話框:IDD_XX
字符串:IDS_XX
DLGINIT:DIALOG_XX
ICON:IDR_XX
.4函數命名
函數原型說明包括引用外來函數及內部函數，外部引用必須在右側注明函數來源：模
塊名及文件名, 如是內部函數，只要注釋其定義文件名;
第一個字母必須使用大寫字母,要求用大小寫字母組合規范函數命名,必要時可用下劃線
間隔,示例如下：
void UpdateDB_Tfgd (TRACK_NAME); file://Module Name :r01/sdw.c
void PrintTrackData (TRACK_NAME); file://Module Name :r04/tern.c
void ImportantPoint (void); file://Module Name :r01/sdw.c
void ShowChar (int , int , chtype); file://Local Module
void ScrollUp_V (int , int); file://Local Module
.5結構體命名
結構體類型命名必須全部用大寫字母,原則上前面以下劃線開始;結構體變量命名必須用
大小寫字母組合，第一個字母必須使用大寫字母,必要時可用下劃線間隔。對於私有數
據區，必須注明其所屬的進程。全局數據定義只需注意其用途。
示例如下：
typedef struct
{
char szProductName[20];
char szAuthor[20];
char szReleaseDate[16];
char szVersion[10];
unsigned long MaxTables;
unsigned long UsedTables;
}DBS_DATABASE;
DBS_DATABASE GdataBase;
6 控件的命名：
用小寫前綴表示類別
用小寫前綴表示類別：
fm 窗口
cmd 按鈕
cob combo，下拉式列表框
txt 文本輸入框
lab labal，標簽
img image，圖象
pic picture
grd Grid，網格
scr 滾動條
lst 列表框
frm fram
7注釋
原則上注釋要求使用中文;
文件開始注釋內容包括:公司名稱、版權、作者名稱、時間、模塊用途、背景介紹等,復
雜的算法需要加上流程說明;
函數注釋包括:輸入、輸出、函數描述、流程處理、全局變量、調用樣例等,復雜的函數
需要加上變量用途說明;
程序中注釋包括:修改時間和作者、方便理解的注釋等;
引用一: 文件開頭的注釋模板
/******************************************************************
** 文件名:
** Copyright (c) 1998-1999 *********公司技術開發部
** 創建人:
** 日 期:
** 修改人:
** 日 期:
** 描 述:
**
** 版 本:
**--------------------------------------------------------------------------
---
******************************************************************/
引用二: 函數開頭的注釋模板
/*****************************************************************
** 函數名:
** 輸 入: a,b,c
** a---
** b---
** c---
** 輸 出: x---
** x 為 1, 表示...
** x 為 0, 表示...
** 功能描述:
** 全局變量:
** 調用模塊:
** 作 者:
** 日 期:
** 修 改:
** 日 期:
** 版本
****************************************************************/
引用三: 程序中的注釋模板
/*----------------------------------------------------------*/
/* 注釋內容 */
/*----------------------------------------------------------*/
8 程序
a. 程序編碼力求簡潔，結構清晰，避免太多的分支結構及太過於技巧性的程序，
盡量不采用遞歸模式。
b. 編寫程序時，亦必須想好測試的方法，換句話說，”單元測試” 的測試方案應
在程序編寫時一並擬好。
c. 注釋一定要與程序一致。
d. 版本封存以後的修改一定要將老語句用/* */ 封閉，不能自行刪除或修改,並要
在文件及函數的修改記錄中加以記錄。
e. 程序中每個block 的開頭 ”{" 及 "}” 必須對齊，嵌套的block 每進一套，
縮進一個tab，TAB 為4個空格,block類型包括if、for、while、do等關鍵字引出的。
f. 對於比較大的函數，每個block 和特殊的函數調用，都必須注明其功能，舉例如下
：
count.divisor = 1193280 / freq; // compute the proper count
OutByte((unsigned short)67, (unsigned char)182); // tell 8253 that a
count is coming
OutByte((unsigned short)66, count. c[0]); // send low-order byte
OutByte((unsigned short)66, count. c[1]); // send high-order byte
×××××××××××××××××××××××××××××××××××××××
bcb，delphi中的變量命名：
遵循匈牙利命名法，命
名必須有意義，制定如下規定
窗體：以大寫的W開始，如About版權窗體， 命名為WAbout
文件：以大寫的F開始，如About版權窗體，文件命名為FAbout.cpp
按鈕(Button)：如退出按鈕，命名為btnExit
……
基類：加base標記，如報表基類,窗體命名為：WBaseRep, 文件命名為FBaseRep.cpp
轉貼
> 1. 在.h/.cpp的開頭應有一段格式統一的說明，內容包括：
> a. 文件名 (FileName)；
> b. 創建人 (Creater)；
> c. 文件創建時間 (Date)；
> d. 簡短說明文件功能、用途 (Comment)。
好習慣
> 2. 除非極其簡單，否則對函數應有注釋說明。內容包括：功能、入口/出口參數，必
要
> 時還可有備注或補充說明。
還是好習慣
> 3. 每列代碼的長度推薦為 80列，最長不得超過120列；折行以對齊為准。
太寬了，我的限制是60列，因為文本方式下屏幕一共80列，如果你用BC這一類的編輯
器，窗口邊框等又要占據一定空間，所以80列太寬
> 4. 循環、分支代碼，判斷條件與執行代碼不得在同一行上。
很對
> 5. 指針的定義，* 號既可以緊接類型，也可以在變量名之前。
>
> 例：可寫做：int* pnsize;
>
> 也可寫做：int *pnsize;
>
> 但不得寫做：int * pnsize;
建議采用第二種，除非附加另外一條規定：一次只聲明一個變量，否則就會讓人混淆，
比如：
int* a, b;
看起來b好像也是個指針，其實不是。
> 6. 在類的成員函數內調用非成員函數時，在非成員函數名前必須加上"::"。
這一條我倒覺得並不是必需的，我的看法是決不要讓你的類成員函數和全局函數的名稱
相同（或類似）
> 7. 函數入口參數有缺省值時，應注釋說明。
>
> 例：BOOL CWpsDib::PaintDIB(CDC* pDC, CRect& rc,
> int nBrightness, file://*=0*//
> BOOL bGrayScale file://*=FALSE*// )
每個變量寫一行，必要時加上/*in, out*/注釋
> 8. else if 必須寫在一行。
應該盡量避免else if這樣的結構
> 9. 與‘{’、‘}’有關的各項規定：
>
> 9.1‘{’、‘}’應獨占一行。在該行內可有注釋。
> 9.2 ‘{’必須另起一行，‘{’ 之後的代碼必須縮進一個Tab。‘{’與‘}’必須在
同
> 一列上。
> 9.3 在循環、分支之後若只有一行代碼，雖然可省略‘{’、‘}’，但不推薦這麼
> 做。若省略後可能引起歧義，則必須加上‘{’、‘}’。
持保留意見，因為GNU的代碼規范是這樣的：
if ( NULL == ptr )
{
// do something here
}
或者
if ( NULL == ptr ) {
// do something here
}
爭論哪個更好並沒有意義，關鍵是統一，如果用VC當然你的辦法最方便，可是如果你用
emacs或者vi，就不是這樣了。
10. 與空格有關的各項規定。
10.1 在所有兩目、三目運算符的兩邊都必須有空格。在單目運算符兩端不必空格。
但在‘—>’、‘::’、‘.’、‘[’、‘]’等運算符前後，及‘&’（取地址）、‘*’（取值）等運算符之後不得有空格。
10.2 for、while、if 等關鍵詞之後應有1個空格，再接‘(’，之後無空格；在結
尾的‘)’前不得有空格。
我認為在括號兩端加空格並不是什麼錯誤，尤其是在一個條件十分復雜的if語句裡
括號兩端不得有空格。
10.3 調用函數、宏時，‘(’、‘)’前後不得有空格。
10.4 類型強制轉換時，‘(’‘)’前後不得有空格
同上
11. 與縮進有關的各項規定
>
> 11.1 縮進以 Tab 為單位。1 個 Tab 為 4 個空格
我認為這個值應該更大，我自己使用8個空格，如果你的代碼因為縮進幅度太大而導致
折行，那麼幾乎可以肯定你的程序設計方案有問題。
> 11.2 下列情況，代碼縮進一個 Tab:
> 1. 函數體相對函數名及'{'、'}'。
> 2. if、else、for、while、do 等之後的代碼。
> 3. 一行之內寫不下，折行之後的代碼，應在合理的位置進行折行。若有 + - * / 等
運
> 算符，則運算符應在上一行末尾，而不應在下一行的行首。
這一條我反對，運算符應該放在下一行行首，以使人能清楚的知道這一行是續上一行
的，比如
if ( something
&& somethingelse
&& otherthings )
如果寫做
if ( something &&
somethingelse &&
otherthings )
反而看不清楚
> 11.3 下列情況，不必縮進：switch 之後的 case、default
