最重要的一致性規則是命名管理，命名風格直接可以直接確定命名實體是：型別、變數、函式、常量、巨集等等，無需查詢實體宣告，我們大腦中的模式匹配引擎依賴於這些命名規則。
命名規則具有一定隨意性，但相比按個人喜好命名，一致性更重要，所以不管你怎麼想，規則總歸是規則。
1. 通用命名規則（general naming rules）
函式命名、變數命名、檔案命名應具有描述性，不要過度縮寫，型別和變數應該是名詞，函式名可以用「命令性」動詞。
如何命名：
盡可能給出描述性名稱，不要節約空間，讓別人很快理解你的**更重要，好的命名選擇：
int num_errors; // good.
int num_completed_connections; // good.
醜陋的命名使用模糊的縮寫或隨意的字元：
int n; // bad - meaningless.
int nerr; // bad - ambiguous abbreviation.
int n_comp_conns; // bad - ambiguous abbreviation.
型別和變數名一般為名詞：如fileopener、num_errors。
函式名通常是指令性的，如openfile()、set_num_errors()，訪問函式需要描述的更細緻，要與其訪問的變數相吻合。
縮寫：
除非放到專案外也非常明了，否則不要使用縮寫，例如：
// good
// these show proper names with no abbreviations.
int num_dns_connections; // most people know what "dns" stands for.
int price_count_reader; // ok, price count. makes sense.
// bad!
// abbreviations can be confusing or ambiguous outside a small group.
int wgc_connections; // only your group knows what this stands for.
int pc_reader; // lots of things can be abbreviated "pc".
不要用省略字母的縮寫：
int error_count; // good.
int error_cnt; // bad.
2. 檔案命名（file names）
檔名要全部小寫，可以包含下劃線（_）或**（- ），按專案約定來。
可接受的檔案命名：
my_useful_class.cc
my-useful-class.cc
myusefulclass.cc
c++檔案以.cpp結尾，標頭檔案以.h結尾。
不要使用已經存在於/usr/include下的檔名（譯者注，對unix、linux等系統而言），如db.h。
通常，盡量讓檔名更加明確，http_server_logs.h就比logs.h要好，定義類時檔名一般成對出現，如foo_bar.h和foo_bar.cc，對應類foobar。
內聯函式必須放在.h檔案中，如果內聯函式比較短，就直接放在.h中。如果**比較長，可以放到以-inl.h結尾的檔案中。對於包含大量內聯**的類，可以有三個檔案：
url_table.h // the class declaration.
url_table.cc // the class definition.
url_table-inl.h // inline functions that include lots of code.
3. 型別命名（type names）
型別命名每個單詞以大寫字母開頭，不包含下劃線：myexcitingclass、myexcitingenum。
所有型別命名——類、結構體、型別定義（typedef）、列舉——使用相同約定，例如：
// classes and structs
class urltable
全域性變數：
對全域性變數沒有特別要求，少用就好，可以以g_或其他易與區域性變數區分的標誌為字首。
5. 常量命名（constant names）
在名稱前加k：kdaysinaweek。
所有編譯時常量（無論是區域性的、全域性的還是類中的）和其他變數保持些許區別，k後接大寫字母開頭的單詞：
const int kdaysinaweek = 7;6. 函式命名（function names）
普通函式（regular functions，譯者注，這裡與訪問函式等特殊函式相對）大小寫混合，訪問函式（accessors and mutators）則要求與變數名匹配：myexcitingfunction()、myexcitingmethod()、my_exciting_member_variable()、set_my_exciting_member_variable()。
普通函式：
函式名以大寫字母開頭，每個單詞首字母大寫，沒有下劃線：
addtableentry()訪問函式：deleteurl()
訪問函式要與訪問的變數名匹配，這兒摘錄乙個擁有例項變數num_entries_的類：
class myclass其他短小的內聯函式名也可以使用小寫字母，例如，在迴圈中呼叫這樣的函式甚至都不需要快取其值，小寫命名就可以接受。void set_num_entries(int num_entries)
private:
int num_entries_;
};
譯者注：從這一點上可以看出，小寫的函式名意味著可以直接內聯使用。
7. 命名空間（namespace names）
命名空間的名稱是全小寫的，其命名基於專案名稱和目錄結構：google_awesome_project。
關於命名空間的討論和如何命名，參考第二篇命名空間。
8. 列舉命名（enumerator names）
列舉值應全部大寫，單詞間以下劃線相連：my_exciting_enum_value。
列舉名稱屬於型別，因此大小寫混合：urltableerrors。
enum urltableerrors ;9. 巨集命名（macro names）
你並不打算使用巨集，對吧？如果使用，像這樣：my_macro_that_scares_small_children。
參考第四篇預處理巨集，通常是不使用巨集的，如果絕對要用，其命名像列舉命名一樣全部大寫、使用下劃線：
#define round(x) ...10. 命名規則例外（exceptions to naming rules）#define pi_rounded 3.0
my_exciting_enum_value
bigopen()函式名，參考open()uinttypedef型別定義bigposstruct或
class，參考pos
sparse_hash_mapstl相似實體；參考stl命名約定
longlong_max常量，類似int_max
Google C 程式設計風格指南
每乙個c 程式設計師都知道，c 具有很多強大的語言特性，但這種強大不可避免的導致它的複雜，這種複雜會使得 更易於出現bug 難於閱讀和維護。本指南的目的是通過詳細闡述在c 編碼時要怎樣寫 不要怎樣寫來規避其複雜性。這些規則可在允許 有效使用c 語言特性的同時使其易於管理。使用前置宣告，盡量少.h檔案...
Google C 程式設計風格指南
越來越發現一致的程式設計風格的重要性，於是把google的c 程式設計風格指南看了一遍，這裡記錄下於自己有益的rules。當規則有多個選擇時，這裡只記錄個人習慣的用法，並不代表它是唯一的用法。google style guide google開源專案風格指南 命名管理是最重要的一致性規則，因此我把它...
Google C 風格指南 閱讀筆記
這個google c 風格指南出得太好了，有很多c 的問題，其實通過閱讀這份文件就可以了。相信讀完後，可以在簡歷上加上一句，具有良好的編碼風格 哈哈。下面記錄一下我的讀書筆記吧。整份文件的中文版本我已經上傳到了資源裡面。每次eclipse cdt新建乙個class的時候，都是做了define保護 所...