(c++ coding standards: 101 rules, guidelines, and best practices)
組織及策略上的問題(organizational and policy issues)
- 0. 不拘小節（或：了解什麼不需要被規範化）。
- 1. 在高警告級別下乾淨地編譯。
- 2. 使用自動化的構建（build）系統
- 3. 使用版本控制系統（version control system）。
- 4. 在**複查上投資。
設計風格(design style)
- 5. 給每乙個實體分配乙份內聚的職責。
- 6. 以正確，簡單，清晰為上。
- 7. 了解何時及如何為可伸縮性編寫**。
- 8. 不要過早地優化。
- 9. 不要過早地退而求次。
- 10. 將全域性和共享的資料減至最少。
- 11. 隱藏資訊。
- 12. 了解何時及如何為併發性編寫**。
- 13. 確保資源為物件所占有。使用顯式的raii和智慧型指標。
程式設計風格(coding style)
- 14. 寧可在編譯和鏈結時出錯也不要在執行時出錯。
- 15. 主動使用const。
- 16. 避免使用巨集。
- 17. 避免使用魔數（magic numbers）。
- 18. 盡可能區域性地宣告變數。
- 19. 始終初始化變數。
- 20. 避免太長的函式。避免太深的巢狀。
- 21. 避免不同的編譯單元在初始化過程中的依賴關係。
- 22. 將定義時的依賴性降至最低。避免迴圈依賴性。
- 23. 保證標頭檔案的自足性（make header files self-sufficient）。
- 24. 始終用內部#include防護哨。絕對不要用外部#include防護哨。
函式與操作符(functions and operators)
- 25. 通過值，（智慧型）指標，或引用適當地取得引數。
- 26. 在過載操作符時，要保留被過載操作符的自然語義。
- 27. 最好是保持算術和賦值運算子的標準形式。
- 28. 最好是保持標準形式的++和--。最好是呼叫字首的形式。
- 29. 考慮通過過載來避免隱式的型別轉換。
- 30. 避免過載&&, ||, 或, (逗號）。
- 31. 不要編寫對函式引數的求值順序有依賴性的**。
名字空間與模組(namespaces and modules)
- 57. 把型別和它的非成員函式介面放在同乙個名字空間中。
- 58. 除非有意讓型別和函式協作，否則把它們放在單獨的名字空間中。
- 59. 不要在標頭檔案中或#include語句之前寫名字空間層級的using。
- 60. 避免在不同的模組中分配和釋放記憶體。
- 61. 不要在標頭檔案中定義具有鏈結屬性的實體（entities with linkage）。
- 62. 不要讓異常在傳遞時跨越模組的邊界。
- 63. 在模組的介面中使用可移植的型別。
錯誤處理與異常(error handling and exceptions)
- 68. 大量使用斷言來說明內部的假設和不變性。
- 69. 設立一套合理的錯誤處理策略，並嚴格遵循。
- 70. 區分錯誤與非錯誤。
- 71. 設計並編寫能夠安全地處理錯誤的**。
- 72. 盡量用異常來報告錯誤。
- 73. 丟擲值，捕獲引用。
- 74. 適當地報告，處理並轉換錯誤。
- 75. 避免異常規格（exception specifications）。
stl容器(stl: containers)
- 76. 預設情況下使用vector。否則選擇其它合適的容器。
- 77. 用vector和string取代陣列。
- 78. 使用vector（以及string::c_str）來和非c++ api交換資料。
- 79. 僅在容器中儲存值和智慧型指標。
- 80. 與其它方法相比，要盡量使用push_back來擴大容器。
- 81. 與單元素操作相比，要盡量使用區間操作。
- 82. 使用公認的慣用法來真正地縮小容量以及真正地刪除元素。
stl演算法(stl: algorithms)
- 83. 使用乙個帶檢查的（checked）stl實現。
- 84. 與手工編寫的迴圈相比，要盡量呼叫stl演算法。
- 85. 使用正確的stl查詢演算法。
- 86. 使用正確的stl排序演算法。
- 87. 使predicate成為純函式（pure function）。
- 88. 在用作演算法和比較器（comparer）時，要優先用函式物件來代替函式。
- 89. 正確地編寫函式物件（function object）。
型別安全性(type safety)
- 90. 避免型別選擇（type switching）；盡量使用多型。
- 91. 依賴於物件型別，而不要依賴於物件的表示方法。
- 92. 避免使用reinterpret_cast。
- 93. 避免用static_cast來強制轉換指標型別。
- 94. 避免強制去除const。
- 95. 不要用c風格的強制型別轉換。
- 96. 不要對非pod型別使用memcpy或memcmp。
- 97. 不要用union來重新解釋資料。
- 98. 不要使用varargs（省略號）。
- 99. 不要使用無效的物件。不要使用不安全的函式。
- 100. 不要以多型方式處理陣列。
C 程式設計規範
關於組織和策略問題 0 不要拘泥於小節 了解哪些東西不應該標準化 類 函式和列舉 likethis 變數名 likethis 私有成員變數名 likethis 巨集名稱 like this。1 在高警告級別乾淨利落地進行編譯 2 使用自動構建系統 3 使用版本控制系統 最廉價也最流行的版本控制系統是...
c程式設計規範
c c 程式設計規範 1 檔案結構 每個c c 程式通常分為兩個檔案。乙個檔案用於儲存程式的宣告 declaration 稱為標頭檔案。另乙個檔案用於儲存程式的實現 implementation 稱為定義 definition c c 程式的標頭檔案以 h 為字尾，c 程式的定義檔案以 c 為字尾，...
《C 程式設計規範》
1 使用編譯器的最高警告級別，成功的構建應該是無聲無息的 沒有警告的 如果確定是無害警告，且是無法修改的第三方標頭檔案引起的，可以用自己的標頭檔案包裝起來，並有選擇性的關閉警告，然後專案中使用該標頭檔案。pragma warning push 僅禁用此標頭檔案 pragma warning disa...