C++ Coding Standards:Summary of Summaries-組織和方針問題與設計風格

By Herb Sutter, Andrei Alexandrescu 著

樹人 譯

組織 和 方 針問題

0.      不要為小事斤斤計較。（或者說是：知道什麼東西不需要标準化）

少說廢話，撿有必要的說：不要把個人的品味或廢棄的實踐強加于他人。

1.      在高警告級别下幹淨地編譯代碼。

要把警告放在心上：使用你的編譯器的最高警告級别。要求幹淨（沒有警告）的建構。了解所有的警告。通過修改你的代碼來消除警告，而不是降低警告級别。

2.      使用自動建構系統。

觸動單一的按鈕：使用一個不需人工幹預的建構整個工程的完全自動化（“單動作”）的建構系統。

3.      使用版本控制系統。

好記性不如爛筆頭：使用版本控制系統（VCS）。永遠不要讓檔案長時間地簽出（check out）。在你通過更新的單元測試後，要經常性地簽入（check in）。使得簽入的代碼不會破壞建構。

4.      投資于代碼評審。

評審代碼：人多力量大。向他人展示你的代碼，閱讀其他人的代碼。大家都将受益。

設計風格

5.      一個實體一個内聚的責任。

一個時刻關注一件事情：賦予每個實體（變量，類，函數，名字空間，子產品，庫）一個定義明确的責任。随着實體的演化，其責任的作用域也随之加大，但其責任不能發散。

6.      正确性，簡單性和清晰性是第一位的。

KISS（保持軟體簡單）：正确優于快速。簡單優于複雜。清晰優于伶俐。安全優于不安全。（參見Item83和Item99）

7.      知道什麼時候和如何為可伸縮性編碼。

小心爆炸性的資料增長：不要過早地優化，着眼于漸進的複雜度。

對于作用于使用者資料的算法，資料處理的複雜度應該是可預測的，最好是不比線性差。在證明了優化是有必要而且重要以後（特别是由資料量增加所引起的），應該集中于提高big-Oh複雜度，而不是作像少用一個額外的加法那樣的優化。

8.      不要過早地優化。

無故加鞭（拉丁諺語Spur not a willing horse）：過早地優化是沒有結果的,就像它很令人着迷一樣。

優化的第一個原則是：不要去動它。優化的第二個原則（隻對專家來說）是：還是不要去動它。衡量兩次，優化一次。

9.      不要過早地悲觀。

自己要輕松點，代碼也是一樣：在其他所有的情況都相同的情況下（尤其是代碼複雜性和可讀性），使用某個有效的設計模式和編碼慣用法應該是你信手拈來的事，而且它不能比悲觀的候選方法更難于編寫。這并不是過早的優化；它是在避免沒有必要的悲觀。

10.  使全局和共享資料最少。

共享會引起争奪：避免共享資料，尤其是全局資料。共享資料會增加耦合性，它降低了可維護性，而且常常會降低效率。

11.  隐藏資訊。

不要洩密：不要暴露一個提供了抽象的實體的内部資訊。

12.  知道什麼時候和如何為并行編碼。

線程安全：如果你的應用程式使用了多線程或多程序，你就應該盡可能地減少共享對象（參見Item10），而且要安全地共享這些對象。

13.  保證資源被對象所擁有。使用顯式的的 RAII 和智能指針。

當你有動力工具時，不要手工去鋸：C++的“資源擷取既是初始化”（RAII）慣用法是一個強大的正确的資源處理工具。RAII允許編譯器提供強大而且自動化的保證，而在别的語言中這些保證需要脆弱的手工編寫的慣用法來提供。在申請一塊原始資源時，随即把它傳遞給一個固有的對象。絕不要在單一一個語句中申請多個資源。