最重要的一致性規則是命名管理。命名風格快速獲知名字代表的是什么東西：類型？變量？函數？常量？宏…？甚至不需要去查找類型聲明。我們大腦中的模式匹配引擎可以非?？煽康奶幚磉@些命名規則。
命名規則具有一定的隨意性，但相比較個人喜好命名，一致性更重要。所以不管你怎么想，規則總是規則。
函數命名，變量命名，文件命名要有描述性，少用縮寫。
盡可能給有描述性的命名，別心疼空間，畢竟讓代碼易于新讀者理解很重要。不要用只有項目開發者能理解的縮寫，也不要通過砍掉幾個字母來縮寫單詞。
下面給出一些通用原則的示例：
int PRice_count_reader; // 無縮寫int num_errors; // "num"本來就很常見，可以縮寫int num_dns_connections; // 人人都知道“DNS”是什么下面的命名規則盡量避免：
int n; // 莫名其妙int nerr; // 怪縮寫int n_comp_conns; // 怪縮寫int wgc_connections; // 只有貴團隊知道這是什么東西int pc_reader; // "pc"有太多可能的解釋了int cstmr_id; // 有刪減若干字母文件名要全部小寫，可以包含下劃線（_）或者連字符（-），按照項目約定來。如果沒有項目約定，則“_”更好?？梢越邮艿奈募?/p>* my_useful_class.cc* my-useful-class.cc* myusefulclass.cc* myusefulclass_test.cc // "_unittest"和"_regtest"已經棄用
C++文件要以.cc結尾（為什么不是.cpp呢？）。頭文件以.h結尾。專門插入文本的文件則以.inc結尾，參見關于頭文件的規則。
不要使用已經存在于/usr/include下的文件名（即編譯器搜索系統頭文件的路徑），如db.h。
通常應盡量讓文件名更加明確。http/_server/_logs.h就比logs.h要好。定義類時文件名一般成對出現，如foo/_bar.h和foo/_bar.cc，對應于類FooBar。
內聯函數必須放在.h文件中，如果內聯函數比較短， 就直接放在.h中。
類型名稱的每個單詞首字母均大寫，不包含下劃線：MyExcitingClass，MyExcitingEnum。
所有類型命名——類，結構體，類型定義（typedef），枚舉——均使用相同約定。例如：
// classes and structsclass UrlTable { ...class UrlTableTester { ...struct UrlTableProperties { ...// typedefstypedef hash_map<UrlTableProperties*, string> PropertiesMap;// enumsenum UrlTableErrors { ...變量名一律小寫，單詞之間用下劃線連接。類的成員變量以下劃線結尾，但結構體的就不用。例如：a_local_variable, a_struct_data_member, a_class_data_member_。
普通變量命名的舉例：
string table_name; // 可以——用下劃線string tablename; // 可以——全小寫string tableName; // 差——混合大小寫（但這似乎是java的命名規則？）類數據成員：
不管是靜態的還是非靜態的，類數據成員都可以和普通變量一樣，彈藥接下劃線。class TableInfo {...private: string table_name_; // 可以——尾后加下劃線 string tablename_; // 可以 static Pool<TableInfo>* pool_; // 可以};結構體變量：
不管是靜態的還是非靜態的，結構體數據成員都可以和普通變量一樣，不用像類那樣接下劃線。結構體與類的討論請參考 結構體vs. 類 一節。struct UrlTableProperties { string name; int num_entries;}全局變量：
對全局變量沒有特別要求，少用就好，但如果你要用，可以用g_或其它標志作為前綴，以便更好的區分局部變量。在全局或者類里的常量名稱前加k：kDaysInAWeek。且除去開頭的k之外每個單詞開頭字母均大寫。
所有編譯時常量，無論是局部的，全局的還是類中的，和其他變量稍微區別一下。k后接大寫字母開頭的單詞。這規則也適用于編譯時的局部作用域常量，不過要按變量規則來命名也可以。
const int kDaysInAWeek = 7;常規函數使用大小寫混合，取值和設置函數則要求與變量名匹配：MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable()。
常規函數：
函數名的每個單詞首字母大寫，沒有下劃線。如果您的某函數出錯時就要直接crash，那么就在函數名加上OrDie，但這函數本身必須集成在產品代碼里，且平時也可能會出錯。AddTableEntry()DeleteUrl()OpenFileOrDie()取值和設值函數：
取值（accessors）和設值（Mutators）函數要與存取的變量名匹配。這兒摘錄一個類，num_entries_是該類的實例變量：class MyClass {public: ... int num_entries() const { return num_entries_; } void set_num_entries(int num_entries) { num_entries_ = num_entries; }private: int num_entries_;};其它非常短小的內聯函數名也可以用小寫字母，例如，如果你在循環中調用這樣的函數甚至都不用緩存器返回值，小寫命名就可以接受。名字空間用小寫字母命名，并基于項目名稱和目錄結構：google_awesome_project。
關于名字空間的討論和如何命名，參考 名字空間 一節。
枚舉的命名應當和常量或者宏一致：kEnumName或者ENUM_NAME。
單獨的枚舉值應該優先蠶蛹常量的命名方式，但宏方式的命名也可以接受。枚舉名UrlTableErrors（以及AlternateUrlTableErrors）是類型，所以要用大小寫混合的方式。
enum UrlTableErrors { kOK = 0, kErrorOutOfMemory, kErrorMalformatedInput,};enum AlternateUrlTableErrors { OK = 0, OUT_OF_MEMORY = 1, MALFORMATED_INPUT = 2,};2009年1月之前，我們一直建議采用宏的方式命名枚舉值。由于枚舉值和宏之間的命名沖突，直接導致了很多問題。由此，這里改為優先選擇常量風格的命名方式。新代碼應該盡可能優先使用常量風格。但是老代碼沒必要切換到常量風格，除非宏風格確實會產生編譯期問題。
你并不打算使用宏，對吧？如果你一定要用，像這樣命名：MY_MACRO_THAT_SCARES_SMALL_CHILDREN。
參考預處理宏。通常不應該使用宏，如果不得不用，其命名像枚舉命名一樣全部大寫，使用下劃線：
#define ROUND(X) ...#define PI_ROUNDED 3.0如果你命名的實體與已有的C/C++實體相似，可參考現有命名策略。
bigopen(); // 函數名，參照open()的形式uint:bigpos: // struct或者class，參照pos的形式sparse_hash_map: // STL相似實體，參照STL命名約定LONGLONG_MAX: // 常量，如同INT_MAXTextQuery::TextQuery(std::string Word) : word/_(word) {},其中word_自然是類內私有成員。但是Google的命名規則也并不是完美的。事實上。例如在類內對于存取函數和其它函數采用不同的命名規則，會有時候令人迷惑（個人體驗）。其它命名規則也有其好處。例如CGAL類庫中的命名規則我覺得就有如下好處：1）類成員變量以m_XX命名，在編程時只要打出m_，編輯器就可以自動彈出所有類成員變量可供選擇；2）指針變量以pXXX開始，使人一看就知道該變量是指針類型的，而Google命名規則中沒有區分指針變量和非指針變量；3）類成員函數的命名中單詞之間以下劃線分開，讓人更容易看清（Google的命名規則中，如果函數名很長，需要讀者仔細去辨認單詞的組成，進而推斷函數的作用）。新聞熱點
疑難解答
圖片精選
