C 編碼規範101

2022-02-03 09:32:59 字數 2320 閱讀 5903

組織和策略問題 第0條 不要拘泥於小節(又名:了解哪些東西不應該標準化) 第1條 在高警告級別乾淨利落地進行編譯 第2條 使用自動構建系統 第3條 使用版本控制系統 第4條 在**審查上投入

設計風格 第5條 乙個實體應該只有乙個緊湊的職責 第6條 正確、簡單和清晰第一 第7條 程式設計中應知道何時和如何考慮可伸縮性 第8條 不要進行不成熟的優化 第9條 不要進行不成熟的劣化 第10條 儘量減少全域性和共享資料 第11條 隱藏資訊 第12條 懂得何時和如何進行併發性程式設計 第13條 確保資源為物件所擁有。使用顯式的raii和智慧型指標

程式設計風格 第14條 寧要編譯時和連線時錯誤,也不要執行時錯誤 第15條 積極使用const 第16條 避免使用巨集 第17條 避免使用「魔數」 第18條 盡可能區域性地宣告變數 第19條 總是初始化變數 第20條 避免函式過長,避免巢狀過深 第21條 避免跨編譯單元的初始化依賴 第22條 儘量減少定義性依賴。避免迴圈依賴 第23條 標頭檔案應該自給自足   

第24條 總是編寫內部#include保護符,決不要編寫外部#include保護符

函式與操作符 第25條 正確地選擇通過值、(智慧型)指標或者引用傳遞引數 第26條 保持過載操作符的自然語義 第27條 優先使用算術操作符和賦值操作符的標準形式 第28條 優先使用++和--的標準形式。優先呼叫字首形式 第29條 考慮過載以避免隱含型別轉換 第30條 避免過載&&、||或 ,(逗號) 第31條 不要編寫依賴於函式引數求值順序的**

類的設計與繼承 第32條 弄清所要編寫的是哪種類 第33條 用小類代替巨類 第34條 用組合代替繼承 第35條 避免從並非要設計成基類的類中繼承 第36條 優先提供抽象介面 第37條 公用繼承即可替換性。繼承,不是為了重用,而是為了被重用 第38條 實施安全的改寫 第39條 考慮將虛函式宣告為非公用的,將公用函式宣告為非虛擬的 第40條 要避免提供隱式轉換 第41條 將資料成員設為私有的,無行為的聚集(c語言形式的struct)除外 第42條 不要公開內部資料 第43條 明智地使用pimpl 第44條 優先編寫非成員非友元函式 第45條 總是一起提供new和delete 第46條 如果提供類專門的new,應該提供所有標準形式(普通、就地和不丟擲)

構造、析構與複製 第47條 以同樣的順序定義和初始化成員變數 第48條 在建構函式中用初始化代替賦值 第49條 避免在建構函式和析構函式中呼叫虛函式 第50條 將基類析構函式設為公用且虛擬的,或者保護且非虛擬的 第51條 析構函式、釋放和交換絕對不能失敗 第52條 一致地進行複製和銷毀 第53條 顯式地啟用或者禁止複製 第54條 避免切片。在基類中考慮用轉殖代替複製 第55條 使用賦值的標準形式 第56條 只要可行,就提供不會失敗的swap(而且要正確地提供)

名字空間與模組 第57條 將型別及其非成員函式介面置於同一名字空間中 第58條 應該將型別和函式分別置於不同的名字空間中,除非有意想讓它們一起工作 第59條 不要在標頭檔案中或者#include之前編寫名字空間using 第60條 要避免在不同的模組中分配和釋放記憶體 第61條 不要在標頭檔案中定義具有鏈結的實體 第62條 不要允許異常跨越模組邊界傳播 第63條 在模組的介面中使用具有良好可移植性的型別

模板與泛型 第64條 理智地結合靜態多型性和動態多型性 第65條 有意地進行顯式自定義 第66條 不要特化函式模板 第67條 不要無意地編寫不通用的**

錯誤處理與異常 第68條 廣泛地使用斷言記錄內部假設和不變式 第69條 建立合理的錯誤處理策略,並嚴格遵守 第70條 區別錯誤與非錯誤 第71條 設計和編寫錯誤安全** 第72條 優先使用異常報告錯誤 第73條 通過值丟擲,通過引用捕獲 第74條 正確地報告、處理和轉換錯誤 第75條 避免使用異常規範

stl:容器 第76條 預設時使用vector。否則,選擇其他合適的容器 第77條 用vector和string代替陣列 第78條 使用vector(和string::c_str)與非c++ api交換資料 第79條 在容器中只儲存值和智慧型指標 第80條 用push_back代替其他擴充套件序列的方式 第81條 多用範圍操作,少用單元素操作 第82條 使用公認的慣用法真正地壓縮容量,真正地刪除元素

stl:演算法 第83條 使用帶檢查的stl實現 第84條 用演算法呼叫代替手工編寫的迴圈 第85條 使用正確的stl查詢演算法 第86條 使用正確的stl排序演算法 第87條 使謂詞成為純函式 第88條 演算法和比較器的引數應多用函式物件少用函式 第89條 正確編寫函式物件

型別安全 第90條 避免使用型別分支,多使用多型 第91條 依賴型別,而非其表示方式 第92條 避免使用reinterpret_cast 第93條 避免對指標使用static_cast 第94條 避免強制轉換const 第95條 不要使用c風格的強制轉換 第96條 不要對非pod進行memcpy操作或者memcmp操作 第97條 不要使用聯合重新解釋表示方式 第98條 不要使用可變長引數(...) 第99條 不要使用失效物件。不要使用不安全函式 第100條 不要多型地處理陣列

c 編碼規範101條

c 編碼規範101條 組織和策略問題 第0條 不要拘泥於小節 又名 了解哪些東西不應該標準化 第1條 在高警告級別乾淨利落地進行編譯 第2條 使用自動構建系統 第3條 使用版本控制系統 第4條 在 審查上投入 設計風格 第5條 乙個實體應該只有乙個緊湊的職責 第6條 正確 簡單和清晰第一 第7條 程...

C 程式設計規範101條

第1條 在高警告級別乾淨利落地進行編譯 第2條 使用自動構建系統 第3條 使用版本控制系統 第4條 做 審查 設計風格 程式設計風格 容器1 類 函式 列舉的名稱形如likethis,每個單詞首字母都大寫。2 變數的名字如likethis,第二個單詞首字母大寫 3 類中私有成員變數名形如liketh...

C 編碼規範

c 編碼規範 規範的制定原則 1 參照微軟在vs.net中,c 既有的規範來制定 2 方便 的交流和維護。3 不影響編碼的效率,不與大眾習慣衝突。4 使 更美觀 閱讀更方便。5 使 的邏輯更清晰 更易於理解。規範的遵守原則 1 如果是軟體外包專案,並且對方制定了 的編寫規範,則首先要遵守對方的編碼規...