C++ 編程規範

標籤：速度   相互   出現   檔案   重要   空格   成員   規範   only   

C++ 編程規範

這是一本 由兩位世界頂級專家聯袂巨獻，適合所有層次 C++程式員 的 C++ 界20年集大成之作，這裡有 101 條關於 C++ 編程的規則、總則與最佳實務。

編程規範與人的關係

好的編程規範能夠帶來下列許多相互關聯的優點：

改善代碼品質

鼓勵開發人員一貫地正確行事，從而能夠直接提高軟體的品質和可維護性。

提高開發速度

開發人員不需要總是從一些基本原則出發進行決策。

增進團隊精神

有助於減少在一些小事上不必要的爭論，使團隊成員更容易閱讀和維護其他成員的代碼。

在正確的方向刪取得一致

使開發人員放開手腳，在有意義的方向上發揮創造性。

第0條：不要拘泥於小節

（又名：瞭解哪些東西不應該標準化）

只規定需要規定的事情

• 不要強制施加個人喜好或者過時的做法:

  有些問題只是個人喜好，並不影響程式的正確性或可讀性，所以這些問題不應該出現在編程規範中，任何專業程式員都可以很容易地閱讀和編寫與其習慣的格式略有不同的代碼。

在每個源檔案和項目中使用一致的格式

• 同一段代碼中要在幾種編程風格(style)之間換來換去是很不舒服的。
• 但是無需再多重專案或者整個公司範圍內強制實施一致的格式。

這裡我們列舉幾種常見的情況，重要的不是設定規則，而是與所維護的檔案中已使用的體例保持一致：

不要規定縮排多少

• 應該規定要用縮排來體現代碼的結構；
• 縮排空格的數量可以遵照個人習慣；

• 但是至少在每個檔案中保持一致。

  不要強制行的具體長度
• 應該保證程式碼的長度有利於閱讀；
• 可以遵照個人習慣來決定行長，但是不要過長；

• 研究表明，文章長度不超過10個單詞最利於閱讀。

不要在命名方面規定過多

應該規定的是使用一致的命名規範：只有兩點是必需的：

• 1.不要使用晦澀的名稱
  即以底線開始或者包含雙底線的名稱

• 2.總是使用形如 ONLY_UPPERCASE_NAMES 的 全大寫字母表示宏 ，

  • 不要考慮使用常見的詞或者縮減語作為宏的名稱（包括常見的模板參數，比如T和U，#define T anything 這樣的代碼是極容易混淆的）；

  • 另外，應該使用一致的、有意義的名稱，遵循檔案的或者模組的規範，如果你無法決定自己的命名規範，可以嘗試如下的命名規範：

    • 類、函數和枚舉的名稱形如LikeThis,即單字首大寫；
    • 變數形如likeThis_;
    • 宏名形如LIKE_THIS。

不要規定注釋體例

• 除非需要使用工具從特定的體例中提取出文檔；
• 應該編寫有用的注釋；
• 儘可能編寫代碼而不是注釋；
• 不要在注釋中重複學代碼語義，這樣很容易產生不一致；

• 應該編寫的是解釋方法和原理的說明性注釋。

  不要嘗試實施陳舊的規則

• 即使他們曾經子一些比較陳舊的編程規範中出現過。

C++ 編程規範