一． 原則：
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,系統監視器等。
拓寬知識面。多參閱其它編程語言、數據庫知識、編譯原理、網絡協議等，熟悉硬件設備、底層匯編、數字邏輯電路等。使用和揣摩其它軟件功能和界面，集百家之長，做出有創新意義和有特色的功能性軟件。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
