原文地址：Google C++ Style Guide
Google的開源項目大多使用C++開發(fā)。每一個C++程序員也都知道，C++具有很多強大的語言特性，但這種強大不可避免的導(dǎo)致它的復(fù)雜，這種復(fù)雜會使得代碼更易于出現(xiàn)bug、難于閱讀和維護。
本指南的目的是通過詳細(xì)闡述在C++編碼時要怎樣寫、不要怎樣寫來規(guī)避其復(fù)雜性。這些規(guī)則可在允許代碼有效使用C++語言特性的同時使其易于管理。
風(fēng)格，也被視為可讀性，主要指稱管理C++代碼的習(xí)慣。使用術(shù)語風(fēng)格有點用詞不當(dāng)，因為這些習(xí)慣遠不止源代碼文件格式這么簡單。
使代碼易于管理的方法之一是增強代碼一致性，讓別人可以讀懂你的代碼是很重要的，保持統(tǒng)一編程風(fēng)格意味著可以輕松根據(jù)“模式匹配”規(guī)則推斷各種符號的含義。創(chuàng)建通用的、必需的習(xí)慣用語和模式可以使代碼更加容易理解，在某些情況下改變一些編程風(fēng)格可能會是好的選擇，但我們還是應(yīng)該遵循一致性原則，盡量不這樣去做。
本指南的另一個觀點是C++特性的臃腫。C++是一門包含大量高級特性的巨型語言，某些情況下，我們會限制甚至禁止使用某些特性使代碼簡化，避免可能導(dǎo)致的各種問題，指南中列舉了這類特性，并解釋說為什么這些特性是被限制使用的。
由Google開發(fā)的開源項目將遵照本指南約定。
注意：本指南并非C++教程，我們假定讀者已經(jīng)對C++非常熟悉。
通常，每一個.cc文件（C++的源文件）都有一個對應(yīng)的.h文件（頭文件），也有一些例外，如單元測試代碼和只包含main()的.cc文件。
正確使用頭文件可令代碼在可讀性、文件大小和性能上大為改觀。
下面的規(guī)則將引導(dǎo)你規(guī)避使用頭文件時的各種麻煩。
1. #define的保護
所有頭文件都應(yīng)該使用#define防止頭文件被多重包含（multiple inclusion），命名格式當(dāng)是：<PROJECT>_<PATH>_<FILE>_H_
為保證唯一性，頭文件的命名應(yīng)基于其所在項目源代碼樹的全路徑。例如，項目foo中的頭文件foo/src/bar/baz.h按如下方式保護：
#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif // FOO_BAR_BAZ_H_
2. 頭文件依賴
使用前置聲明（forward declarations）盡量減少.h文件中#include的數(shù)量。
當(dāng)一個頭文件被包含的同時也引入了一項新的依賴（dependency），只要該頭文件被修改，代碼就要重新編譯。如果你的頭文件包含了其他頭文件，這些頭文件的任何改變也將導(dǎo)致那些包含了你的頭文件的代碼重新編譯。因此，我們寧可盡量少包含頭文件，尤其是那些包含在其他頭文件中的。
使用前置聲明可以顯著減少需要包含的頭文件數(shù)量。舉例說明：頭文件中用到類File，但不需要訪問File的聲明，則頭文件中只需前置聲明class File;無需#include "file/base/file.h"。
在頭文件如何做到使用類Foo而無需訪問類的定義？
1) 將數(shù)據(jù)成員類型聲明為Foo *或Foo &；
2) 參數(shù)、返回值類型為Foo的函數(shù)只是聲明（但不定義實現(xiàn)）；
3) 靜態(tài)數(shù)據(jù)成員的類型可以被聲明為Foo，因為靜態(tài)數(shù)據(jù)成員的定義在類定義之外。
另一方面，如果你的類是Foo的子類，或者含有類型為Foo的非靜態(tài)數(shù)據(jù)成員，則必須為之包含頭文件。
有時，使用指針成員（pointer members，如果是scoped_ptr更好）替代對象成員（object members）的確更有意義。然而，這樣的做法會降低代碼可讀性及執(zhí)行效率。如果僅僅為了少包含頭文件，還是不要這樣替代的好。
當(dāng)然，.cc文件無論如何都需要所使用類的定義部分，自然也就會包含若干頭文件。
譯者注：能依賴聲明的就不要依賴定義。
3. 內(nèi)聯(lián)函數(shù)
只有當(dāng)函數(shù)只有10行甚至更少時才會將其定義為內(nèi)聯(lián)函數(shù)（inline function）。
定義（Definition）：當(dāng)函數(shù)被聲明為內(nèi)聯(lián)函數(shù)之后，編譯器可能會將其內(nèi)聯(lián)展開，無需按通常的函數(shù)調(diào)用機制調(diào)用內(nèi)聯(lián)函數(shù)。
優(yōu)點：當(dāng)函數(shù)體比較小的時候，內(nèi)聯(lián)該函數(shù)可以令目標(biāo)代碼更加高效。對于存取函數(shù)（accessor、mutator）以及其他一些比較短的關(guān)鍵執(zhí)行函數(shù)。
缺點：濫用內(nèi)聯(lián)將導(dǎo)致程序變慢，內(nèi)聯(lián)有可能是目標(biāo)代碼量或增或減，這取決于被內(nèi)聯(lián)的函數(shù)的大小。內(nèi)聯(lián)較短小的存取函數(shù)通常會減少代碼量，但內(nèi)聯(lián)一個很大的函數(shù)（譯者注：如果編譯器允許的話）將戲劇性的增加代碼量。在現(xiàn)代處理器上，由于更好的利用指令緩存（instruction cache），小巧的代碼往往執(zhí)行更快。
結(jié)論：一個比較得當(dāng)?shù)奶幚硪?guī)則是，不要內(nèi)聯(lián)超過10行的函數(shù)。對于析構(gòu)函數(shù)應(yīng)慎重對待，析構(gòu)函數(shù)往往比其表面看起來要長，因為有一些隱式成員和基類析構(gòu)函數(shù)（如果有的話）被調(diào)用！
另一有用的處理規(guī)則：內(nèi)聯(lián)那些包含循環(huán)或switch語句的函數(shù)是得不償失的，除非在大多數(shù)情況下，這些循環(huán)或switch語句從不執(zhí)行。
重要的是，虛函數(shù)和遞歸函數(shù)即使被聲明為內(nèi)聯(lián)的也不一定就是內(nèi)聯(lián)函數(shù)。通常，遞歸函數(shù)不應(yīng)該被聲明為內(nèi)聯(lián)的（譯者注：遞歸調(diào)用堆棧的展開并不像循環(huán)那么簡單，比如遞歸層數(shù)在編譯時可能是未知的，大多數(shù)編譯器都不支持內(nèi)聯(lián)遞歸函數(shù)）。析構(gòu)函數(shù)內(nèi)聯(lián)的主要原因是其定義在類的定義中，為了方便抑或是對其行為給出文檔。
4. -inl.h文件
復(fù)雜的內(nèi)聯(lián)函數(shù)的定義，應(yīng)放在后綴名為-inl.h的頭文件中。
在頭文件中給出內(nèi)聯(lián)函數(shù)的定義，可令編譯器將其在調(diào)用處內(nèi)聯(lián)展開。然而，實現(xiàn)代碼應(yīng)完全放到.cc文件中，我們不希望.h文件中出現(xiàn)太多實現(xiàn)代碼，除非這樣做在可讀性和效率上有明顯優(yōu)勢。
如果內(nèi)聯(lián)函數(shù)的定義比較短小、邏輯比較簡單，其實現(xiàn)代碼可以放在.h文件中。例如，存取函數(shù)的實現(xiàn)理所當(dāng)然都放在類定義中。出于實現(xiàn)和調(diào)用的方便，較復(fù)雜的內(nèi)聯(lián)函數(shù)也可以放到.h文件中，如果你覺得這樣會使頭文件顯得笨重，還可以將其分離到單獨的-inl.h中。這樣即把實現(xiàn)和類定義分離開來，當(dāng)需要時包含實現(xiàn)所在的-inl.h即可。
-inl.h文件還可用于函數(shù)模板的定義，從而使得模板定義可讀性增強。
要提醒的一點是，-inl.h和其他頭文件一樣，也需要#define保護。
5. 函數(shù)參數(shù)順序（Function Parameter Ordering）
定義函數(shù)時，參數(shù)順序為：輸入?yún)?shù)在前，輸出參數(shù)在后。
C/C++函數(shù)參數(shù)分為輸入?yún)?shù)和輸出參數(shù)兩種，有時輸入?yún)?shù)也會輸出（譯者注：值被修改時）。輸入?yún)?shù)一般傳值或常數(shù)引用（const references），輸出參數(shù)或輸入/輸出參數(shù)為非常數(shù)指針（non-const pointers）。對參數(shù)排序時，將所有輸入?yún)?shù)置于輸出參數(shù)之前。不要僅僅因為是新添加的參數(shù)，就將其置于最后，而應(yīng)該依然置于輸出參數(shù)之前。
這一點并不是必須遵循的規(guī)則，輸入/輸出兩用參數(shù)（通常是類/結(jié)構(gòu)體變量）混在其中，會使得規(guī)則難以遵循。
6. 包含文件的名稱及次序
將包含次序標(biāo)準(zhǔn)化可增強可讀性、避免隱藏依賴（hidden dependencies，譯者注：隱藏依賴主要是指包含的文件中編譯時），次序如下：C庫、C++庫、其他庫的.h、項目內(nèi)的.h。
項目內(nèi)頭文件應(yīng)按照項目源代碼目錄樹結(jié)構(gòu)排列，并且避免使用UNIX文件路徑.（當(dāng)前目錄）和..（父目錄）。例如，google-awesome-project/src/base/logging.h應(yīng)像這樣被包含：
#include "base/logging.h"
dir/foo.cc的主要作用是執(zhí)行或測試dir2/foo2.h的功能，foo.cc中包含頭文件的次序如下：
dir2/foo2.h（優(yōu)先位置，詳情如下）
C系統(tǒng)文件
C++系統(tǒng)文件
其他庫頭文件
本項目內(nèi)頭文件
這種排序方式可有效減少隱藏依賴，我們希望每一個頭文件獨立編譯。最簡單的實現(xiàn)方式是將其作為第一個.h文件包含在對應(yīng)的.cc中。
dir/foo.cc和dir2/foo2.h通常位于相同目錄下（像base/basictypes_unittest.cc和base/basictypes.h），但也可在不同目錄下。
相同目錄下頭文件按字母序是不錯的選擇。
舉例來說，google-awesome-project/src/foo/internal/fooserver.cc的包含次序如下：
#include "foo/public/fooserver.h" // 優(yōu)先位置
#include <sys/types.h>
#include <unistd.h>
#include <hash_map>
#include <vector>
#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/public/bar.h"
______________________________________
譯者：英語不太好，翻譯的也就不太好。這一篇主要提到的是頭文件的一些規(guī)則，總結(jié)一下：
1. 避免多重包含是學(xué)編程時最基本的要求；
2. 前置聲明是為了降低編譯依賴，防止修改一個頭文件引發(fā)多米諾效應(yīng)；
3. 內(nèi)聯(lián)函數(shù)的合理使用可提高代碼執(zhí)行效率；
4. -inl.h可提高代碼可讀性（一般用不到吧:D）；
5. 標(biāo)準(zhǔn)化函數(shù)參數(shù)順序可以提高可讀性和易維護性（對函數(shù)參數(shù)的堆?？臻g有輕微影響，我以前大多是相同類型放在一起）；
6. 包含文件的名稱使用.和..雖然方便卻易混亂，使用比較完整的項目路徑看上去很清晰、很條理，包含文件的次序除了美觀之外，最重要的是可以減少隱藏依賴，使每個頭文件在“最需要編譯”（對應(yīng)源文件處:D）的地方編譯，有人提出庫文件放在最后，這樣出錯先是項目內(nèi)的文件，頭文件都放在對應(yīng)源文件的最前面，這一點足以保證內(nèi)部錯誤的及時發(fā)現(xiàn)了。