前言：代碼規範是工程質量的基石
良好的編程規範不僅關乎美觀，更直接決定軟件的可維護性、可靠性、團隊協作效率。本文整理自經典工程實踐，涵蓋基本要求、可讀性、結構化、正確性與容錯性四大維度，供團隊參考落地。
一、基本要求
- 結構清晰，簡單易懂：單個函數不超過 100 行（建議 50 行以內），超過即拆分。
- 意圖明確，代碼精簡：拒絕「垃圾代碼」（死代碼、過度設計、冗餘邏輯），直觀表達業務意圖。
- 優先復用標準庫/公共組件：不重複造輪子，減少 Bug 面，提升一致性。
- 慎用全局變量：優先局部變量、參數傳遞、單例模式、依賴注入，降低耦合與副作用。
- 善用括號消除二義性：即使優先級明確，複雜表達式也加括號，防止誤讀與編譯器差異。
二、可讀性要求（可讀性第一，效率第二）
- 註釋與代碼同步維護：錯誤的註釋比無註釋更有害。
- 文件頭註釋：模塊名、作者、日期、版本、功能描述、依賴、修改記錄。
- 函數頭註釋：功能、參數（輸入/輸出/輸入輸出）、返回值、異常、副作用、調用示例、演算法說明。
- 關鍵變量/類型定義處註釋：業務含義、取值範圍、單位、不變量。
- 常量/宏定義註釋：來源、含義、單位、為何取此值。
- 處理階段註釋：每個邏輯階段（初始化、計算、輸出等）前加註釋。
- 典型算法註釋：引用來源、複雜度、關鍵步驟、邊界條件處理。
- 統一縮進：Tab 鍵，寬度 4 或 8 空格（團隊統一），禁用空格混雜。
- 嵌套層級 ≤ 5 層：超過即重構（提取函數、衛語句、狀態機、策略模式）。
- 註釋位置靈活：行末或上行，保持一致。
- 利用空行/空白分隔邏輯塊：視覺分組，減輕認知負荷。
- 顯而易見代碼免註釋：
i++; 無需註釋「i 加 1」。
- 註釋作用域明確：針對定義、引用、分支、代碼塊。
- 註釋密度 1/5 ~ 1/3：不含文件/函數頭，有效註釋行 / 總代碼行。
三、結構化要求（拒絕面條代碼）
- 禁止等價雙分支：
if (a) foo(); else foo(); → 直接 foo();。
- 禁用 GOTO：異常處理用
try/catch/finally、RAII、錯誤碼返回。
- IF 強調二選一：禁用
else goto、else return（衛語句除外）。
- 多路分支用 Switch/Case：或查表法、策略模式、多態替代長鏈 if-else。
- 循環單一出口：避免多
break/return，用標志變量或提取函數。
- 函數單一出口：SESE (Single Entry Single Exit)，便於調試、清理、擴展（現代觀點允許衛語句早期返回）。
- 不用條件賦值：
x = (a > b) ? a : b; → 明確 if-else，或用 std::max。
- 消除冗餘分支：
if (cond) return true; else return false; → return cond;。
- 邏輯表達式優於條件分支：
if (a && b) return true; 而非嵌套 if。
四、正確性與容錯性要求（程序先正確，後優美）
- 先正確，後優美：功能正確是一切前提。
- 自我審查：寫完先讀三遍，再跑測試，再提交。
- 修改影響分析：改一處，思考十處（依賴、調用者、並發、持久化、配置、日志、監控）。
- 變量使用前必初始化：消除未定義行為，編譯器警告視為錯誤 (
-Werror)。
- 所有用戶輸入必驗證：類型、範圍、格式、長度、編碼、注入攻擊（SQL/XSS/命令注入）。
- 禁用浮點數直接比較相等：
fabs(a - b) < EPSILON 或整數定點運算。
- 主動處理環境/狀態異常：文件鎖、打印機離線、網絡超時、磁盤滿、權限不足、配置缺失——預設失敗，優雅降級。
- 單元測試是編程一部分：提交聯調前必須通過單測（覆蓋率、邊界、異常路徑）。
落地建議
- 工具鏈固化：
clang-format/astyle 格式化、cpplint/SonarQube 靜態檢查、commit-hook 強制規範。
- Code Review 清單化：將上述條目制成 Checklist，人人遵守。
- 新人入職培訓：以規範為教材，實戰演練。
- 定期重構專項：專門清理違規項（超長函數、魔術數字、深層嵌套）。
- 規範演進：隨語言標準（C++11/14/17/20）、項目需求迭代更新，避免僵化。
總結
編程規範不是束縛，而是自由的邊界。在規範內寫代碼，才能專注於業務創新而非格式糾結；才能在重構時大膽落筆而不恐懼副作用；才能讓團隊代碼如出一轍，實現真正的集體所有制。從今天開始，嚴格要求自己，每一行代碼都經得起審視。
