前人總結的一些軟體開發規範

為了提高軟體開發品質，降低開發週期，增強代碼的可重用性和易讀性，使軟體便於維護，開發人員間便於交流和協作，特總結出開發規範，以為參考。

一． 原則：

1． 軟體工程化
2． 模組化
3． 能簡單不複雜
4． 強調團隊協作
5． 強調創新和特色

二． 具體規範：

1． 命名規範
命名應盡量使用匈牙利命名法，變數名或函數名中使用大寫字元來區分各個部分，以便於記憶和閱讀。如bPatchMinute, DeleteDirInfo()。全域(包括類中的)變數用長名字，局部變數用短名字。
類成員變數前一般應加上m_，全域變數加上g_，僅與本模組有關的變數加上l_,緊接著是變數的類型。
整型： n,i
長整型: l
無符號整型： u
無符號長整型：dw
字元： ch
布爾量： b
浮點數: f
雙精確度浮點: d
字串： str,lpsz,sz,p,lp,ac,
指標： p
位元組指標： pb
無符號指標： pv
字元指標： lpsz
整型指標： lpn
檔案指標： fp
如：
m_nTotalNum,m_strPath,m_bRcving,m_fPrice,g_lOpenDate,g_dwCardNo,lpszNameStr, lpnSysDoomType,uMsgID,m_pProgress

局部變數應盡量易懂簡潔，使用常見的變數，如
Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename
臨時變數，如ltmp,ftmp,tmpStr,tempStr,

函數命名也應該見名知意。如CalcAllDataStyle(),ReadDocDataFromTime(),GetIndexInfo()
常見的函數
Init, OpenAll, Create_, Get_, Set_, Read_, Load_, Write_, Start_, Stop_, Check_, Test_, Fill_, Process_, Sort_, Do_, Select_, Is_, Exist_,_Ex。

宏命名和typedef定義類型應詳細，避免重複，一律為大寫，如

#define DEL_EMPTY(a) {if (a) {delete a;a=NULL;}}
#define SUCCESS 0
#define FAIL -1

typedef struct
{
char lpzSource[100];
char lpzTitle[100];
char lpzURL[194];
short nType;
long npos;
long nlen;
}ATTBODY,*LPATTBODY; （指標前加LP）

自訂訊息從WM_USER開始
#define MYAPP_MESSAGE WM_USER+0x1001

2． 代碼規範
有些不易理解的變數或函數應作注釋，難懂的代碼要有註解，在檔案的開始處有該檔案的用途描述。一定要保持注釋的一致性。

程式碼群組織要清晰，{,},(,),if,else,do,while,for,case等要對應整齊，少用空格，縮排全部用Tab鍵。變數的定義要集中，函數間要有空行分開，一個程式中的空行數目最好佔8%-16%。多態函數和功能相近的函數集中放在一起。

代碼應該簡潔、清楚並講述了所發生的一切，我們的目標應該是寫出最清晰的代碼，而不是最巧妙的代碼。例如如果是MFC多文檔程式，就要嚴格按照其產生的架構寫代碼。盡量使用編譯器已經提供的函數，不必花時間另行編寫。例如系統已經有qsort函數，可直接拿來排序用。

某些公用代碼要注意多平台易移植，最好使用標準C。

代碼的重用要仔細，要將相關的代碼也拷貝過來，注意那段代碼也許不適合你的應用場合。

刪掉從來沒有用過的函數或變數，大篇幅注釋掉的程式碼也應刪除，以免使程式混亂難讀。

3． 工程檔案組織規範
一個工程往往包含很多很多檔案（*.h,*.cpp,*.inc,*.lib,資源檔等），向工程中加入檔案或刪除工程中的檔案要謹慎，避免把工程損壞。工程中不起作用的檔案或類應刪除，工程目錄下的非工程檔案也應該移走，保持工程的清潔，避免混淆難於管理。工程檔案如果很多，應歸類。

在VC環境下，建議將常用的標頭檔全部放入stdafx.h中，而在每個cpp開始處嵌入stdafx.h。避免標頭檔的交叉引用，如果有嚴重的交叉引用，適當使用類的聲明。

將獨立性比較強的模組抽出來，做成DLL，控制項或COM組件，該模組可單獨編寫和測試，也增強了其可重用性。

一個比較大的工程應留有一定的訊息介面或外掛程式介面等。

工程的版本控制要嚴格，版本格式為xx.xx.xx，必要時使用Build次數或日期。高版本盡量相容低版本的用法、資料或協議。

工程的編譯宏定義和工程參數設定應正確，每作一個新工程時應檢查工程參數是否正確。
建議位元組對齊為1位元組對齊。

工程檔案應經常備份，備份時註明備份日期和主要增加的功能。

4． 類組織規範
類一般有兩個檔案，一個標頭檔，一個實現體CPP。

類力求封裝好，嚴格區分public,private,protect等範圍，如果一個函數與本類有莫大的關係，可以作為該類的靜態成員函數，不用或少用友元函數等破壞類封裝性的方法和技巧。 如果一些結構或宏僅與本類有關，可在類標頭檔中定義。

類的成員變數在建構函式或初始化函數中應賦初值。指標在建構函式中賦NULL,析構時DEL_EMPTY它，以免記憶體泄露。

5． 使用者介面規範
有四大類型的使用者介面：對話方塊、單一文件介面、多重文件介面、其它介面

對話方塊要易用且簡潔，字型和控制項的組織搭配要得體，能簡單不複雜，各控制項的焦點、Tab順序等要講究，視應用場合要適當支援鍵盤。在簡潔易用的前提下，力求個人化，設計得更加友好。程式各對話方塊的風格要保持一致。

單文檔和多重文件介面的程式功能可以做得很強，也便於擴充和管理。其中菜單、工具列、狀態列等設計要有特色。菜單按一定的分類彈出，必要時設計成多套菜單，在重要的視窗或地區應能彈出右鍵，實現常見操作。工具列上放最常用的操作按鈕，必要時動態更換按鈕。狀態列顯示足夠多的有用資訊。
訊息主控在Mainframe中，單文檔的主控也可在View中，所有的對話方塊的彈出或非模態對話方塊的控制都在主控視窗中完成，具體的資料處理放在單獨的檔案中或設計成類。在App類中實現Ini讀寫，各資料對象的定義和析構，全域變數的賦值和初始計算，存檔退出等。各視圖的OnDraw和GDI畫圖盡量使用記憶體位元影像的方式，以免閃爍。

其它還有ATL，控制台，嵌入式程式介面等，也有作為其它容器如IE中的外掛程式等，此類程式可能不用MFC，而採用COM組件等方法實現。

6． 疑難解答和Bug調試方法
勤問、善於問。在不打擾正常工作的前提下，開發人員間應相互協助，聚思廣益，也許你的問題或Bug就是他人的前車之鑒。

從各種途徑請求解答。專業書、教材、期刊、電子文檔以及國際標準文獻、RFC等，Internet上專業網站、論壇、專家組等。

Bug的出現總是有一定的原因的，冷靜尋找，不要總是拘泥於某一個小局部，換一個想法、從另外一個角度也許讓你柳暗花明。使用一些輔助開發或調試工具，如Spy++,Process Viewer,系統監視器等。

拓寬知識面。多參閱其它程式設計語言、資料庫知識、編譯原理、網路通訊協定等，熟悉硬體裝置、底層彙編、數字邏輯電路等。使用和揣摩其它軟體功能和介面，集百家之長，做出有創新意義和有特色的功能性軟體。

三． 一些習慣：

我認為比較好的習慣：

1.if(0 == GetDataType(…))比if(GetDataType(…) == 0) 好，縱使誤將==寫成=，在編譯一層就會報錯。
2.
#define MAX_DOWNLOADNUM 20
struct DownInfo m_DownInfo[MAX_DOWNLOADNUM];
在代碼中盡量不用具體的大小數值，定義成宏，便於以後維護。
3.
CUSTXG_CONTABLE g_lpCustCon[] =
{
{"數值串1",C_ZGB,C_CUSTJBM,C_VT_FBJ,"萬"},
{"數值串2",C_ZSZ,C_CUSTJBM,C_VT_FBJ,"萬"},
…
{"數值比例",C_WTB,C_CUSTHQ,C_VT_FBJ,"%"}
};
int g_nCustNum = sizeof(g_lpCustCon)/sizeof(CUSTXG_CONTABLE);
g_ nCustNum自動適應g_lpCustCon的大小。
4.
函數定義short GetInputType( const char * lpzInput)比short GetInputType (char * lpzInput)好，以免lpzInput在函數體中被破壞。
5.
協議包頭定義成：
typedef struct tagDataHeader
{
struct{
unsigned char Version:4;
unsigned char HeaderFlag:2;
unsigned char Reserved:2;//保留Bits位
}Info;
long nOther;
long Reserved; //保留4個位元組
} DATAHEADER;
定義有一定的保留欄位，供以後擴充使用。
6.
變數在定義時賦初值，類析構時或程式退出時判斷釋放所有變數。
7.
編碼空間一定要充分預留，編碼時注意可擴充性。

我認為不好的習慣：

1. 代碼中是"+2","+4",而不是"+sizeof(short)","+sizeof(int)"。
2. filename[40],而不是filename[MAX_PATH]。
3. GDI資源使用完後不釋放，位元影像、筆刷等用完後不Select出來。這樣會將導致系統Gdi資源丟失或記憶體泄露。
4. 大量使用無符號型變數。無符號變數在判斷時易造成錯誤，甚至死迴圈，盡量少用。
5. 使用malloc,free不使用new,delete,大量使用realloc。new,delete是規範的C++文法，通用性強，realloc易造成記憶體抖動。
6. #define square(x) (x)*(x)
宏的體應加括弧，否則容易出問題，如1/square(x)將被替換1/(x)*(x)