排版
1.關鍵字和操作符之間加適當的空格。
2.相對獨立的程式塊與塊之間加空行
3.較長的語句、表達式等要分成多行書寫。
4.劃分出的新行要進行適應的縮進，使排版整齊，語句可讀。
5.長表達式要在低優先權操作符處劃分新行，操作符放在新行之首。
6.循環、判斷等語句中若有較長的表達式或語句，則要進行適應的劃分。
7.若函式或過程中的參數較長，則要進行適當的劃分。
8.不允許把多個短語句寫在一行中，即一行只寫一條語句。
9.函式或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格。
10.C/C++語言是用大括弧‘{ ’和‘ }’界定一段程式塊的，編寫程式塊時‘{ ’和
‘ }’應各獨占一行並且位於同一列，同時與引用它們的語句左對齊。在函式體
的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、
switch、case語句中的程式都要採用如上的縮進方式。
注釋
1.注釋要簡單明了。
2.邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性。
3.在必要的地方注釋，注釋量要適中。注釋的內容要清楚、明了，含義準確，防止
注釋二義性。保持注釋與其描述的代碼相鄰，即注釋的就近原則。
4.對代碼的注釋應放在其上方相鄰位置，不可放在下面。
5.對數據結構的注釋應放在其上方相鄰位置，不可放在下面；對結構中的每個域
的注釋應放在此域的右方；同一結構中不同域的注釋要對齊。
6.變數、常量的注釋應放在其上方相鄰位置或右方。
7.全局變數要有較詳細的注釋，包括對其功能、取值範圍、哪些函式或過程存取它
以及存取時注意事項等的說明。
8.在每個源檔案的頭部要有必要的注釋信息，包括：檔案名稱；版本號；作者；生成
日期；模組功能描述（如功能、主要算法、內部各部分之間的關係、該檔案與其
它檔案關係等）；主要函式或過程清單及本檔案歷史修改記錄等。
9.在每個函式或過程的前面要有必要的注釋信息，包括：函式或過程名稱；功能描
述；輸入、輸出及返回值說明；調用關係及被調用關係說明等。
命名
1.較短的單詞可通過去掉“元音”形成縮寫；
2.較長的單詞可取單詞的頭幾發符的優先權，並用括弧明確表達式的操作順序，避
免使用默認優先權。
可讀性
1.避免使用不易理解的數字，用有意義的標識來替代。
2.不要使用難懂的技巧性很高的語句。
3.源程式中關係較為緊密的代碼應儘可能相鄰。
變數
1.去掉沒必要的公共變數。
2.構造僅有一個模組或函式可以修改、創建，而其餘有關模組或函式只訪問的公共
變數，防止多個不同模組或函式都可以修改、創建同一公共變數的現象。
3.仔細定義並明確公共變數的含義、作用、取值範圍及公共變數間的關係。
4.明確公共變數與操作此公共變數的函式或過程的關係，如訪問、修改及創建等。
5.當向公共變數傳遞數據時，要十分小心，防止賦與不合理的值或越界等現象發生。
6.防止局部變數與公共變數同名。
7.仔細設計結構中元素的布局與排列順序，使結構容易理解、節省占用空間，並減
少引起誤用現象。
8.結構的設計要儘量考慮向前兼容和以後的版本升級，並為某些未來可能的套用保
留餘地（如預留一些空間等）。
9.留心具體語言及編譯器處理不同數據類型的原則及有關細節。
10.嚴禁使用未經初始化的變數。聲明變數的同時對變數進行初始化。
11.編程時，要注意數據類型的強制轉換。
函式過程
1.函式的規模儘量限制在200行以內。
2.一個函式最好僅完成一件功能。
3.為簡單功能編寫函式。
4.函式的功能應該是可以預測的，也就是只要輸入數據相同就應產生同樣的輸出。
5.儘量不要編寫依賴於其他函式內部實現的函式。
6.避免設計多參數函式，不使用的參數從接口中去掉。
7.用注釋詳細說明每個參數的作用、取值範圍及參數間的關係。
8.檢查函式所有參數輸入的有效性。
9.檢查函式所有非參數輸入的有效性，如數據檔案、公共變數等。
10.函式名應準確描述函式的功能。
11.避免使用無意義或含義不清的動詞為函式命名
12.函式的返回值要清楚、明了，讓使用者不容易忽視錯誤情況。
13/明確函式功能，精確（而不是近似）地實現函式設計。
14.減少函式本身或函式間的遞歸調用。
15.編寫可重入函式時，若使用全局變數，則應通過關中斷、信號量（即P、V操作）
等手段對其加以保護。
可測性
1.在編寫代碼之前，應預先設計好程式調試與測試的方法和手段，並設計好各種調
測開關及相應測試代碼如列印函式等。
2.在進行集成測試/系統聯調之前，要構造好測試環境、測試項目及測試用例，同時
仔細分析並最佳化測試用例，以提高測試效率。
程式效率
1.編程時要經常注意代碼的效率。
2.在保證軟體系統的正確性、穩定性、可讀性及可測性的前提下，提高代碼效率。
3.不能一味地追求代碼效率，而對軟體的正確性、穩定性、可讀性及可測性造成影
響。
4.編程時，要隨時留心代碼效率；最佳化代碼時，要考慮周全。
5.要仔細地構造或直接用彙編編寫調用頻繁或性能要求極高的函式。
6.通過對系統數據結構劃分與組織的改進，以及對程式算法的最佳化來提高空間效率。
7.在多重循環中，應將最忙的循環放在最內層。
8.儘量減少循環嵌套層次。
9.避免循環體內含判斷語句，應將循環語句置於判斷語句的代碼塊之中。
10.儘量用乘法或其它方法代替除法，特別是浮點運算中的除法。
質量保證
1.在軟體設計過程中構築軟體質量。
代碼質量保證優先原則
（1）正確性，指程式要實現設計要求的功能。
（2）穩定性、安全性，指程式穩定、可靠、安全。
（3）可測試性，指程式要具有良好的可測試性。
（4）規範/可讀性，指程式書寫風格、命名規則等要符合規範。
（5）全局效率，指軟體系統的整體效率。
（6）局部效率，指某個模組/子模組/函式的本身效率。
（7）個人表達方式/個人方便性，指個人編程習慣。
2.只引用屬於自己的存貯空間。
3.防止引用已經釋放的記憶體空間。
4.過程/函式中分配的記憶體，在過程/函式退出之前要釋放。
5.過程/函式中申請的（為打開檔案而使用的）檔案句柄，在過程/函式退出前要關閉。
6.防止記憶體操作越界。
7.時刻注意表達式是否會上溢、下溢。
8.認真處理程式所能遇到的各種出錯情況。
9.系統運行之初，要初始化有關變數及運行環境，防止未經初始化的變數被引用。
10.系統運行之初，要對載入到系統中的數據進行一致性檢查。
11.嚴禁隨意更改其它模組或系統的有關設定和配置。
12.不能隨意改變與其它模組的接口。
13.充分了解系統的接口之後，再使用系統提供的功能。
14.要時刻注意易混淆的操作符。當編完程式後，應從頭至尾檢查一遍這些操作符。
15.不使用與硬體或作業系統關係很大的語句，而使用建議的標準語句。
16.建議：使用第三方提供的軟體開發工具包或控制項時，要注意以下幾點：
（1）充分了解套用接口、使用環境及使用時注意事項。
（2）不能過分相信其正確性。
（3）除非必要，不要使用不熟悉的第三方工具包與控制項。
代碼編譯
1.編寫代碼時要注意隨時保存，並定期備份，防止由於斷電、硬碟損壞等原因造成
代碼丟失。
2.同一項目組內，最好使用相同的編輯器，並使用相同的設定選項。
3.合理地設計軟體系統目錄，方便開發人員使用。
4.打開編譯器的所有告警開關對程式進行編譯。
5.在同一項目組或產品組中，要統一編譯開關選項。
6.使用工具軟體（如VisualSourceSafe）對代碼版本進行維護。
代碼測試
1.單元測試要求至少達到語句覆蓋。
2.單元測試開始要跟蹤每一條語句，並觀察數據流及變數的變化。
3.清理、整理或最佳化後的代碼要經過審查及測試。
