1.1的用途
在軟件開發過程中，編碼的工作量是相當大的。參與同壹個項目的人可能有自己的編程經驗和習慣，不同風格的程序代碼使得維護工作變得復雜和困難。為了提高代碼的可讀性，系統的穩定性，降低維護和升級的成本，特編寫本規範，統壹開發者的編程工作。
1.2適用對象
本規範適用於所有開發者，包括應用程序、網頁和數據庫的開發者，以及相關的程序測試人員。
1.3參考標準
GB/T 11457軟件工程術語。
GB 8566計算機軟件開發規範
GB 8567計算機軟件產品開發文檔指南
2.寫作要求
2.1通用代碼規則
可讀性原則，這是評價節目好壞的首選，寧可沒有壹些技巧也要保證節目的可讀性，不要因為過分追求技巧而犧牲節目的可讀性。
功能獨立原則。每個程序塊只完成壹個獨立的功能，反之，每個獨立的功能只在壹個程序塊中完成，盡量低耦合，高內聚。
提示應該簡短，避免歧義。
提示或警告信息應該具有指導性，能夠準確地告訴用戶錯誤的原因和恢復方法。提示和警告對話框應該使用標準規範。
快捷鍵的定義必須符合用戶的操作習慣。
當程序需要處理或等待很長時間時，應該顯示壹個進度條，提示用戶等待。
壹些敏感操作，如刪除，在執行前必須提示用戶確認。
2.2變量、函數、程序和控制的命名規則。
2.2.1變量命名
變量命名由[作用域][數據類型][用戶定義的名稱]規則定義，並遵循匈牙利命名方法。要求壹個變量的作用域和數據類型可以通過看到它的名字直觀地看出來。
匈牙利命名規則:
數組數組
B BOOL (int) Boolean(整數)
按無符號字符(字節)無符號字符(字節)
c字符(字節)
字節計數
Cr顏色參考值顏色(參考)值
x(短整型)x(短整型)的cx計數集
Dw DWORD(無符號長整型)雙字(無符號長整型)
F flags(通用多位值)flag(壹般為多位數的值)。
Fn函數Function
G_全球全球
h手柄手柄
I整數整數
長整型
長指針
a類數據成員的M_ Data成員。
短整型短整型
指針指針
s字符串字符串
以0結尾的字符串。
文本公制文本規則
u無符號int無符號整數
Ul無符號長整型(ULONG)無符號長整型。
w字(無符號短整型)無符號短整型
x，y x，y坐標(短整型)坐標值/短整型。
v空無壹物
行動範圍:
範圍前綴示例
全局範圍g_ g_Servers
成員變量m_ m_pDoc
沒有字符串的局部範圍
數據類型
VC公共前綴列表
前綴類型描述示例
Ch char 8位字符chGrade
Ch TCHAR 16位UNICODE類型字符chName
布爾布爾變量
N int integer(其大小由操作系統決定)nLength
Unint無符號整數(其大小由操作系統決定)nLength
w字16位無符號整數wPos
長32位有符號整數l偏移量
32位無符號整數
內存模塊指針，指針變量pDoc
長指針
32位字符串指針
32位常量字符串指針
32位UNICODE類型常量指針
窗口對象句柄
Lpfn (*fn)()回調函數指針回調到的遠指針。
回調函數lpfnAbort
2.2.2函數和程序的命名
函數體或過程名應該大小寫混合，並且足夠長以描述其功能。此外，函數名應該以動詞開頭，比如InitNameArray或CloseDialog。對於經常使用或較長的項目，建議使用標準縮寫，以使名稱長度合理化。壹般來說，超過32個字符的變量名在VGA顯示器上很難閱讀。使用縮寫時，確保它們在整個應用程序中保持壹致。在壹個項目中，如果壹會兒用Cnt，壹會兒計數，就會導致不必要的混亂。
對於自己編寫的函數，如果是系統關鍵函數，必須在函數實現部分上方標註該函數的信息，格式如下:
//======================================================
//函數名:InsureHasOutputInfo
//函數描述:確保正確的輸出信息。
//輸入參數:nproductive:對應的產品ID。
//輸出參數:void
//創建日期:00-2-21
//修改日期:00-2-21
//作者:* * *
//附加說明:
//======================================================
用戶定義的類型
在具有許多用戶定義類型的大型項目中，通常需要為每種類型賦予自己的三個字符的前綴。如果這些前綴以“u”開頭，那麽在處理用戶定義的類型時，很容易快速識別這些類型。例如，ucli可以用作用戶定義的客戶類型變量的前綴。
註意:對於非通用變量，請在定義時註明，並盡可能將變量定義放在開頭。
控制命名
對象應該用壹致的前綴命名，這樣人們可以很容易地識別對象的類型。
VC常用宏定義命名列表
前綴符號類型符號示例範圍
IDR_標識多個資源共享的類型* * * IDR_MAINFRAME 1~0x6FFF
IDD _ dialog IDD _ spell _ check 1 ~ 0x 6 fff
HIDD_基於對話框的上下文幫助Hidd _ Spell _ Check 0x 20001 ~ 0x 26 ff
IDB_ bitmap資源(bitmap)IDB _ company _ logo 1 ~ 0x 6 fff
IDC _ cursor IDC _ pencil 1 ~ 0x 6 fff
IDI_圖標資源(圖標)IDI _記事本1~0x6FFF
工具欄或菜單欄的ID_，IDM _ Command Item ID _ TOOLS _ SPELLING 0x 8000 ~ 0x dfff
HID_ command上下文幫助HID _ tools _ spelling 0x 18000 ~ 0x 1 dfff
IDP_ message box提示文本資源IDP _ INVALID _ PARTNO 8 ~ 0xDFFF。
HIDP_消息框上下文幫助hidp _ invalid _ part no 0x 30008 ~ 0x 3d fff
IDS_ string資源(string)IDS _ copyright 1 ~ 0x 7 fff
IDC _ dialog中的控制資源IDC_ Recalc8 ~ 0xdfff
2.3源代碼規則
2.3.1樣式約定:程序的層次結構以縮進格式保存。要求直觀地看到循環、判斷等層次結構。
對於每個嵌套的函數塊，使用制表符縮進(可以設置為4個空格)，大括號必須放在條件語句的下壹行，這是單獨的壹行，這樣括號就要單獨放在壹行。在大多數情況下，反膨脹標誌應該有註釋。例子如下:
if(條件1)
{
while(條件2)
{
… ..
… ..
}//end while(條件2)
}//結束if (condition1)
或者
if(condition1){
while(條件2){
….
….
}//end while(條件2)
}//end if(條件1)
2.3.2運算符前後必須使用空格。
2.3.3在分隔數組下標和函數參數的逗號後面必須添加壹個空格。
2.3.4嚴禁使用go to語句。
2.3.5數據庫操作只能使用標準的SQL語句，關鍵字必須大寫(如SELECT、WHERE等。)，以及數據元素(表、字段、視圖等)。)必須按照數據字典來寫。
2.3.6程序代碼中應有足夠的容錯處理功能。
針對可能的異常統壹使用C++ throw格式:
嘗試
{
//可能引發異常的代碼
扔t；//手動引發異常
}
catch(type _ 1e)//type _ 1是類型定義器，比如int，CException，_com_error。
{
// type_1類型異常處理
}
catch(類型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”)。
\
我是從公司文件上抄下來的！自己看看對妳有沒有用！