最重要的一致性規則是命名管理. 命名風格快速獲知名字代表是什麼東東: 型別? 變數? 函式? 常量? 巨集 ... ? 甚至不需要去查詢型別宣告. 我們大腦中的模式匹配引擎可以非常可靠的處理這些命名規則.
命名規則具有一定隨意性, 但相比按個人喜好命名, 一致性更重, 所以不管你怎麼想, 規則總歸是規則.
tip函式命名，變數命名，檔案命名要有描述性；少用縮寫。
盡可能給有描述性的命名，別心疼空間，畢竟讓**易於新讀者理解很重要。不要用只有專案開發者能理解的縮寫，也不要通過砍掉幾個字母來縮寫單詞。
intprice_count_reader
;// 無縮寫
intnum_errors
;// 「num」 本來就很常見
intnum_dns_connections
;// 人人都知道 「dns」 是啥
warning
intn
;// 莫名其妙。
intnerr
;// 怪縮寫。
intn_comp_conns
;// 怪縮寫。
intwgc_connections
;// 只有貴團隊知道是啥意思。
intpc_reader
;// "pc" 有太多可能的解釋了。
intcstmr_id
;// 有刪減若干字母。
tip檔名要全部小寫, 可以包含下劃線 (_) 或連字元 (-). 按專案約定來. 如果並沒有專案約定，」_」 更好。
可接受的檔案命名:
* my_useful_class.cc* my-useful-class.cc
* myusefulclass.cc
* muusefulclass_test.cc // ``_unittest`` 和 ``_regtest`` 已棄用。
c++ 檔案要以.cc結尾, 標頭檔案以.h結尾. 專門插入文字的檔案則以.inc結尾，參見:ref:self-contained headers。
不要使用已經存在於/usr/include下的檔名 (yang.y 注: 即編譯器搜尋系統標頭檔案的路徑), 如db.h.
通常應盡量讓檔名更加明確.http_server_logs.h就比logs.h要好. 定義類時檔名一般成對出現, 如foo_bar.h和foo_bar.cc, 對應於類foobar.
內聯函式必須放在.h檔案中. 如果內聯函式比較短, 就直接放在.h中.
tip型別名稱的每個單詞首字母均大寫, 不包含下劃線:myexcitingclass,myexcitingenum.
所有型別命名 —— 類, 結構體, 型別定義 (typedef), 列舉 —— 均使用相同約定. 例如:
// classes and structs
class
urltable
;
結構體變數:
不管是靜態的還是非靜態的，結構體資料成員都可以和普通變數一樣, 不用像類那樣接下劃線:結構體與類的討論參考 結構體 vs. 類 一節.struct
urltableproperties
全域性變數:
對全域性變數沒有特別要求, 少用就好, 但如果你要用, 可以用g_或其它標誌作為字首, 以便更好的區分區域性變數.
tip在全域性或類裡的常量名稱前加k: kdaysinaweek. 且除去開頭的k之外每個單詞開頭字母均大寫。
所有編譯時常量, 無論是區域性的, 全域性的還是類中的, 和其他變數稍微區別一下.k後接大寫字母開頭的單詞:
這規則適用於編譯時的區域性作用域常量，不過要按變數規則來命名也可以。const
intkdaysinaweek=7
;
tip常規函式使用大小寫混合, 取值和設值函式則要求與變數名匹配:myexcitingfunction(),myexcitingmethod(),my_exciting_member_variable(),set_my_exciting_member_variable().
常規函式:
函式名的每個單詞首字母大寫, 沒有下劃線。如果您的某函式出錯時就要直接 crash, 那麼就在函式名加上 ordie. 但這函式本身必須整合在產品**裡，且平時也可能會出錯。
addtableentry
()deleteurl
()openfileordie
()
取值和設值函式:
取值（accessors）和設值（mutators）函式要與訪問的變數名匹配. 這兒摘錄乙個類,其它非常短小的內聯函式名也可以用小寫字母, 例如. 如果你在迴圈中呼叫這樣的函式甚至都不用快取其返回值, 小寫命名就可以接受.num_entries_是該類的例項變數:class
myclass
void
set_num_entries
(int
num_entries
)private
:int
num_entries_
;};
tip名字空間用小寫字母命名, 並基於專案名稱和目錄結構:google_awesome_project.
關於名字空間的討論和如何命名, 參考 名字空間 一節.
tip列舉的命名應當和 常量 或 巨集 一致:kenumname或是enum_name.
單獨的列舉值應該優先採用
常量 的命名方式. 但
巨集 方式的命名也可以接受. 列舉名urltableerrors(以及alternateurltableerrors) 是型別, 所以要用大小寫混合的方式.
enum
urltableerrors
;enum
alternateurltableerrors
;
2009 年 1 月之前, 我們一直建議採用 巨集 的方式命名列舉值. 由於列舉值和巨集之間的命名衝突, 直接導致了很多問題. 由此, 這裡改為優先選擇常量風格的命名方式. 新**應該盡可能優先使用常量風格. 但是老**沒必要切換到常量風格, 除非巨集風格確實會產生編譯期問題.
tip你並不打算:ref:使用巨集 , 對吧? 如果你一定要用, 像這樣命名:my_macro_that_scares_small_children.
參考:ref:預處理巨集 ; 通常 不應該 使用巨集. 如果不得不用, 其命名像列舉命名一樣全部大寫, 使用下劃線:
#define round(x) ...
#define pi_rounded 3.0
tip如果你命名的實體與已有 c/c++ 實體相似, 可參考現有命名策略.
bigopen():
函式名, 參照open()的形式
uint:
typedef
bigpos:
struct或class, 參照pos的形式
sparse_hash_map:
stl 相似實體; 參照 stl 命名約定
longlong_max:
常量, 如同int_max
感覺 google 的命名約定很高明，比如寫了簡單的類 queryresult, 接著又可以直接定義乙個變數 query_result, 區分度很好；再次，類內變數以下劃線結尾，那麼就可以直接傳入同名的形參，比如textquery::textquery(std::string
word)
:word_(word)
{}, 其中word_自然是類內私有成員。
Google C 命名約定
函式命名,變數命名,檔案命名要有描述性 少用縮寫.int price count reader 無縮寫 int num errors num 是乙個常見的寫法 int num dns connections 人人都知道 dns 是什麼 int n 毫無意義.int nerr 含糊不清的縮寫.int ...
Google C 程式設計規範 命名約定（部分）
1.通用命名規則 具備描述性，適當縮寫，型別和變數應該是名詞，函式名可以用 命令性 動詞 int num errors good.int num completed connections good.int price count reader 無縮寫 int num errors num 是乙個常...
Google C 程式設計風格指南（五） 命名約定
最重要的一致性規則是命名管理，命名風格直接可以直接確定命名實體是 型別 變數 函式 常量 巨集等等，無需查詢實體宣告，我們大腦中的模式匹配引擎依賴於這些命名規則。命名規則具有一定隨意性，但相比按個人喜好命名，一致性更重要，所以不管你怎麼想，規則總歸是規則。1.通用命名規則 general namin...