1.1的用途
在軟件開發過程中，編碼的工作量相當大。參與同壹個項目的人可能有自己的編程經驗和習慣，不同風格的程序代碼使維護工作變得復雜和困難。為了提高代碼的可讀性、系統的穩定性以及降低維護和升級的成本，特編寫本規範以統壹開發人員的編程工作。
1.2適用對象
本規範適用於所有開發人員，包括應用程序、網頁和數據庫的開發人員以及相關的程序測試人員。
1.3參考標準
GB/T 11457軟件工程術語。
GB 8566計算機軟件開發規範
GB 8567計算機軟件產品開發文檔指南
2.寫作要求
2.1通用代碼規則
可讀性原則，這是評估程序質量的首選，寧可沒有壹些技能也要保證程序的可讀性，不要因為過度追求技能而犧牲程序的可讀性。
職能獨立原則。每個程序塊只完成壹個獨立的功能，反之，每個獨立的功能只在壹個程序塊中完成，盡量低耦合、高內聚。
提示應該簡短並避免歧義。
提示或警告信息應具有指導性，並能準確地告訴用戶錯誤的原因和恢復方法。提示和警告對話框應該使用標準規範。
快捷鍵的定義必須符合用戶的操作習慣。
當程序需要處理或等待很長時間時，應顯示進度條並提示用戶等待。
某些敏感操作（如刪除）必須在執行前提示用戶確認。
2.2變量、函數、程序和控制的命名規則。
2.2.1變量命名
變量命名由【作用域】【數據類型】【用戶定義的名稱】規則定義，並遵循匈牙利命名方法。要求通過看到變量的名字就能直觀地看到變量的作用域和數據類型。
匈牙利命名規則:
數組數組
布爾型（整數）
按無符號字符（字節）無符號字符（字節）
c字符（字節）
字節的Cb計數
顏色參考值顏色（參考）值
x（短整型）x（短整型）的cx計數集
雙字（無符號長整型）
f標誌（通用多位值）標誌（通常是多位數的值）。
Fn函數Function
G_全球全球
h手柄手柄
I整數整數
l長整型
長指針
a類數據成員的M_ Data成員。
短整型短整型
指針指針
s字符串字符串
以0結尾的字符串。
文本公制文本規則
u無符號int無符號整數
Ul無符號長整型（ULONG）無符號長整型。
w字（無符號短整型）
x，y x，y坐標（短整型）坐標值/短整型。
空空的
行動範圍:
範圍前綴示例
全局範圍g_ g_Servers
成員變量m_ m_pDoc
沒有字符串的本地範圍
數據類型
VC公共前綴列表
前綴類型描述示例
Ch char 8位字符chGrade
Ch TCHAR 16位UNICODE類型字符chName
布爾布爾變量被禁用
整數（其大小由操作系統決定）長度
Unint無符號整數（其大小由操作系統決定）nLength
w字16位無符號整數wPos
l長32位有符號整數l偏移量
32位無符號整數
內存模塊指針，指針變量pDoc
長指針
32位字符串指針
32位常量字符串指針
Lpsz LPCTSTR 32位UNICODE類型常量指針lpszName
h句柄Windows對象句柄hWnd
lpfn（* fn）（）回調函數指針回調遠指針指向。
回調函數lpfnAbort
2.2.2函數和程序的命名
函數或過程名的主體應該大小寫混合，並且足夠長以描述其功能。此外，函數名應該以動詞開頭，例如InitNameArray或CloseDialog。對於經常使用或較長的項目，建議使用標準縮寫以使名稱長度合理化。壹般來說，超過32個字符的變量名很難在VGA顯示器上讀取。使用縮寫時，請確保它們在整個應用程序中保持壹致。在壹個項目中，如果壹會兒使用Cnt，壹會兒使用Count，就會導致不必要的混亂。
對於自己編寫的函數，如果是系統關鍵函數，則必須在函數實現部分上方標記該函數的信息，格式如下:
//======================================================
//函數名: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資源（位圖）IDB _ company _ logo1 ~ 0x6fff
IDC _ cursor IDC _ pencil 1 ~ 0x 6 fff
IDI_圖標資源（圖標）IDI _記事本1~0x6FFF
工具欄或菜單欄的ID_，IDM_ Command項目ID_TOOLS_SPELLING 0x8000~0xDFFF
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資源（字符串）ids _ copyright 1 ~ 0x7fff
IDC _ dialog中的控制資源IDC_ Recalc8 ~ 0xdfff
2.3源代碼規則
2.3.1樣式約定:程序的層次結構以縮進格式保存。要求直觀地看到循環、判斷等層次結構。
對於每個嵌套的函數塊，使用制表符縮進（可以設置為4個空格），大括號必須放在條件語句的下壹行，這是壹個單獨的行，因此括號應該放在單獨的行上。在大多數情況下，防擴張標誌應該有註釋。例子如下:
if（condition 1）
{
while（條件2）
{
… ..
… ..
}//end while（條件2）
}//end if（condition 1）
或者
if（condition 1 ）{
while（條件2 ）{
….
….
}//end while（條件2）
}//end if（conditionl）
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類型異常處理
}
漁獲物（類型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”）。
\
我是從公司文件上抄下來的！自己看看是否對妳有用！