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