C++ 編程規範

目錄

• C++ 編程規範
  • 編程規範與人的關係
    • 改善代碼質量
    • 提升開發速度
    • 增進團隊精神
    • 在正確的方向刪取得一致
  • 第0條：不要拘泥於小節
    • 只規定須要規定的事情
    • 在每一個源文件和項目中使用一致的格式
    • 不要規定縮進多少
    • 不要在命名方面規定過多
    • 不要規定註釋體例

C++ 編程規範

這是一本 由兩位世界頂級專家聯袂鉅獻，適合全部層次 C++程序員 的 C++ 界20年集大成之做，這裏有 101 條關於 C++ 編程的規則、總則與最佳實踐。

編程規範與人的關係

好的編程規範可以帶來下列許多相互關聯的優勢：

改善代碼質量

鼓勵開發人員一向地正確行事，從而可以直接提升軟件的質量和可維護性。

提升開發速度

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

增進團隊精神

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

在正確的方向刪取得一致

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

第0條：不要拘泥於小節

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

只規定須要規定的事情

• 不要強制施加我的喜愛或者過期的作法:

  有些問題只是我的喜愛，並不影響程序的正確性或可讀性，因此這些問題不該該出如今編程規範中，任何專業程序員均可以很容易地閱讀和編寫與其習慣的格式略有不一樣的代碼。

在每一個源文件和項目中使用一致的格式

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

這裏咱們列舉幾種常見的狀況，重要的不是設定規則，而是與所維護的文件中已使用的體例保持一致：

不要規定縮進多少

• 應該規定要用縮進來體現代碼的結構；
• 縮進空格的數量能夠遵守我的習慣；

• 可是至少在每一個文件中保持一致。

  不要強制行的具體長度

• 應該保證代碼行的長度有利於閱讀；
• 能夠遵守我的習慣來決定行長，可是不要過長；

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

不要在命名方面規定過多

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

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

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

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

  • 另外，應該使用一致的、有意義的名稱，遵循文件的或者模塊的規範，若是你沒法決定本身的命名規範，能夠嘗試以下的命名規範：

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

不要規定註釋體例

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

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

  不要嘗試實施陳舊的規則

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