c++命名規範

規範的代碼讓程序具備美感，我更願意去閱讀她。

參考google編碼規範 http://zh-google-styleguide.readthedocs.io/en/latest/google-cpp-styleguide/

文件命名

總述

文件名要所有小寫, 能夠包含下劃線 (_) 或連字符 (-), 依照項目的約定. 若是沒有約定, 那麼 「_」 更好.

說明

可接受的文件命名示例:

• my_useful_class.cc
• my-useful-class.cc
• myusefulclass.cc
• myusefulclass_test.cc // _unittest 和 _regtest 已棄用.

C++ 文件要以 .cc 結尾, 頭文件以 .h 結尾. 專門插入文本的文件則以 .inc 結尾, 參見 頭文件自足.

不要使用已經存在於 /usr/include 下的文件名 (Yang.Y 注: 即編譯器搜索系統頭文件的路徑), 如 db.h.

一般應儘可能讓文件名更加明確. http_server_logs.h 就比 logs.h 要好. 定義類時文件名通常成對出現, 如 foo_bar.h 和 foo_bar.cc, 對應於類 FooBar.

內聯函數必須放在 .h 文件中. 若是內聯函數比較短, 就直接放在 .h 中.

**我以前的作法是單詞首字母大寫和類名同樣，也不知道好很差，看arduino庫代碼也是如此。這條就不參照谷歌了。

類型命名

總述

類型名稱的每一個單詞首字母均大寫, 不包含下劃線: MyExcitingClass, MyExcitingEnum.

說明

全部類型命名 —— 類, 結構體, 類型定義 (typedef), 枚舉, 類型模板參數 —— 均使用相同約定, 即以大寫字母開始, 每一個單詞首字母均大寫, 不包含下劃線. 例如:

// 類和結構體
class UrlTable { ... class UrlTableTester { ... struct UrlTableProperties { ... // 類型定義 typedef hash_map<UrlTableProperties *, string> PropertiesMap; // using 別名 using PropertiesMap = hash_map<UrlTableProperties *, string>; // 枚舉 enum UrlTableErrors { ...
**類的命名和我以前的作法一致，只是我不知道類型命名都如此。（類名，結構體名，類型定義，別名，枚舉類名）

變量命名

總述

變量 (包括函數參數) 和數據成員名一概小寫, 單詞之間用下劃線鏈接. 類的成員變量如下劃線結尾, 但結構體的就不用, 如: a_local_variable, a_struct_data_member, a_class_data_member_.

說明

普通變量命名

舉例:

string table_name; // 好 - 用下劃線. string tablename; // 好 - 全小寫. string tableName; // 差 - 混合大小寫 

類數據成員

不論是靜態的仍是非靜態的, 類數據成員均可以和普通變量同樣, 但要接下劃線.

class TableInfo { ... private: string table_name_; // 好 - 後加下劃線. string tablename_; // 好. static Pool<TableInfo>* pool_; // 好. }; 

結構體變量

不論是靜態的仍是非靜態的, 結構體數據成員均可以和普通變量同樣, 不用像類那樣接下劃線:

struct UrlTableProperties { string name; int num_entries; static Pool<UrlTableProperties>* pool; };
**此處靜態和非靜態沒有區分感受很差，不知道在哪看到靜態 s_打頭，全局 g_打頭。下次補上。

 常量命名

總述

聲明爲 constexpr 或 const 的變量, 或在程序運行期間其值始終保持不變的, 命名時以 「k」 開頭, 大小寫混合. 例如:

const int kDaysInAWeek = 7; 

說明

全部具備靜態存儲類型的變量 (例如靜態變量或全局變量, 參見 存儲類型) 都應當以此方式命名. 對於其餘存儲類型的變量, 如自動變量等, 這條規則是可選的. 若是不採用這條規則, 就按照通常的變量命名規則.

**這裏提到全部具備靜態存儲類型的變量 (例如靜態變量或全局變量, 參見 存儲類型) 都應當以此方式命名 ，以 「k」 「s」 "g"開頭, 大小寫混合。

函數命名

總述

常規函數使用大小寫混合, 取值和設值函數則要求與變量名匹配: MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable().

說明

通常來講, 函數名的每一個單詞首字母大寫 (即 「駝峯變量名」 或 「帕斯卡變量名」), 沒有下劃線. 對於首字母縮寫的單詞, 更傾向於將它們視做一個單詞進行首字母大寫 (例如, 寫做 StartRpc() 而非 StartRPC()).

AddTableEntry() DeleteUrl() OpenFileOrDie() 

(一樣的命名規則同時適用於類做用域與命名空間做用域的常量, 由於它們是做爲 API 的一部分暴露對外的, 所以應當讓它們看起來像是一個函數, 由於在這時, 它們其實是一個對象而非函數的這一事實對外不過是一個可有可無的實現細節.)

取值和設值函數的命名與變量一致. 通常來講它們的名稱與實際的成員變量對應, 但並不強制要求. 例如 int count() 與 void set_count(int count).

**我嚴重習慣函數命名首字母小寫，這個仍是保持吧。取值和設值與變量名一致 get_count() ,set_count()。

命名空間命名

總述

命名空間以小寫字母命名. 最高級命名空間的名字取決於項目名稱. 要注意避免嵌套命名空間的名字之間和常見的頂級命名空間的名字之間發生衝突.

頂級命名空間的名稱應當是項目名或者是該命名空間中的代碼所屬的團隊的名字. 命名空間中的代碼, 應當存放於和命名空間的名字匹配的文件夾或其子文件夾中.

注意 不使用縮寫做爲名稱 的規則一樣適用於命名空間. 命名空間中的代碼極少須要涉及命名空間的名稱, 所以沒有必要在命名空間中使用縮寫.

要避免嵌套的命名空間與常見的頂級命名空間發生名稱衝突. 因爲名稱查找規則的存在, 命名空間之間的衝突徹底有可能致使編譯失敗. 尤爲是, 不要建立嵌套的 std 命名空間. 建議使用更獨特的項目標識符 (websearch::index, websearch::index_util) 而很是見的極易發生衝突的名稱 (好比 websearch::util).

對於 internal 命名空間, 要小心加入到同一 internal 命名空間的代碼之間發生衝突 (因爲內部維護人員一般來自同一團隊, 所以常有可能致使衝突). 在這種狀況下, 請使用文件名以使得內部名稱獨一無二 (例如對於 frobber.h, 使用 websearch::index::frobber_internal).

**命名空間這個還沒用到

枚舉命名

總述

枚舉的命名應當和 常量 或 宏 一致: kEnumName 或是 ENUM_NAME.

說明

單獨的枚舉值應該優先採用 常量 的命名方式. 但 宏 方式的命名也能夠接受. 枚舉名 UrlTableErrors(以及 AlternateUrlTableErrors) 是類型, 因此要用大小寫混合的方式.

enum UrlTableErrors { kOK = 0, kErrorOutOfMemory, kErrorMalformedInput, }; enum AlternateUrlTableErrors { OK = 0, OUT_OF_MEMORY = 1, MALFORMED_INPUT = 2, }; 

2009 年 1 月以前, 咱們一直建議採用 宏 的方式命名枚舉值. 因爲枚舉值和宏之間的命名衝突, 直接致使了不少問題. 由此, 這裏改成優先選擇常量風格的命名方式. 新代碼應該儘量優先使用常量風格. 可是老代碼不必切換到常量風格, 除非宏風格確實會產生編譯期問題.

宏命名

總述

你並不打算 使用宏, 對吧? 若是你必定要用, 像這樣命名: MY_MACRO_THAT_SCARES_SMALL_CHILDREN.

說明

參考 預處理宏; 一般 不該該 使用宏. 若是不得不用, 其命名像枚舉命名同樣所有大寫, 使用下劃線:

#define ROUND(x) ...
#define PI_ROUNDED 3.0
**全大寫下滑線分割