(c++ coding standards: 101 rules, guidelines, and best practices)
來信請寄:[email protected]
- 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. 不要編寫對函式引數的求值順序有依賴性的**。
類設計及繼承(class design and inheritance)
- 32. 清楚自己要編寫什麼型別的類。
- 33. 最好是設計最小型的類而不要設計巨型類。
- 34. 優先採用聚合，其次才是繼承。
- 35. 避免繼承自未設計為基類的類。
- 36. 最好是提供抽象介面。
- 37. 公有繼承代表可替換性。繼承，不是為了重用，而是為了被重用。
- 38. 安全地覆蓋虛函式。
- 39. 考慮使虛函式成為非公有函式，使公有函式成為非虛函式。
- 40. 避免提供隱式轉換。
- 41. 使類的資料成員為私有，除非是無行為的聚合類（c風格的結構）。
- 42. 不要洩露你的內部實現。
- 43. 明智地使用pimpl慣用法。
- 44. 最好是編寫非成員非友元函式。
- 45. 始終同時提供new和delete。
- 46. 如果你提供類特有的new，那麼要提供所有的標準形式（plain，in-place，及nothrow）。
構造，析構，及複製操作(construction, destruction, and copying)
- 47. 以相同的順序定義及初始化成員變數。
- 48. 在建構函式中最好是用初始化列表而避免用賦值操作符。
- 49. 避免在建構函式和析構函式中呼叫虛函式。
- 50. 使基類的析構函式成為公有的虛函式，或受保護的非虛函式。
- 51. 析構函式，資源釋放函式，以及swap絕不會失敗。
- 52. 以一致的方式進行複製和銷毀。
- 53. 顯式地允許或禁止複製。
- 54. 避免分割物件。考慮用clone來取代在基類中進行複製。
- 55. 最好是保持賦值操作符的標準形式。
- 56. 只要合理，就（正確地）提供不會失敗的swap。
名字空間與模組(namespaces and modules)
- 57. 把型別和它的非成員函式介面放在同乙個名字空間中。
- 58. 除非有意讓型別和函式協作，否則把它們放在單獨的名字空間中。
- 59. 不要在標頭檔案中或#include語句之前寫名字空間層級的using。
- 60. 避免在不同的模組中分配和釋放記憶體。
- 61. 不要在標頭檔案中定義具有鏈結屬性的實體（entities with linkage）。
- 62. 不要讓異常在傳遞時跨越模組的邊界。
- 63. 在模組的介面中使用可移植的型別。
模板與泛型(templates and genericity)
- 64. 明智地結合靜態多型性和動態多型性。
- 65. 有意地並顯式地定製。
- 66. 不要特化函式模板。
- 67. 不要在無意中編寫不通用的**。
錯誤處理與異常(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. 不要以多型方式處理陣列。
Google C 程式設計規範 中文版
1.標頭檔案 2.作用域 3.類 4.函式 5.來自 google 的奇技 6.其他 c 特性 7.命名約定 7.5.常量命名 7.6.函式命名 7.7.命名空間命名 7.8.列舉命名 7.9.巨集命名 7.10.命名規則的特例 譯者 acgtyrant 筆記 8.注釋 8.3.類注釋 8.4.函式...
WSDL規範1 1 中文版
wsdl規範目前最新的版本是2.0 但是目前大部分還是按1.1的版本進行使用，而且1.1的內容看上去比2.0也簡單些，所以我就翻譯了這個版本。作為一種 炒作過度的技術和概念 的一類，web service的確是太過重量級，對於小型的應用，還是因該避免去使用xml和soap這些技術。但是在企業級的應用...
JSON RPC 2 0規範 翻譯 中文版
json rpc 2.0規範 起源日期 2010 03 26 基於2009 05 24的版本號 修正 2013 01 04 json rpc 工作組 json rpc是乙個無狀態的 輕量級的遠端過程呼叫 rpc 協議。本規範主要環繞它的處理方式定義了幾個資料結構和規則。這個概念可用於在同一程序中 套...