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等，Inte.net上專業網站、論壇、專家組等。
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)
以上僅是我總結的一些，比較少，希望能拋磚引玉，請大家補充
文章來源于領測軟件測試網 http://www.kjueaiud.com/
