google開源c\c++專案程式碼規範
google開源 C / C ++專案程式碼規範
1.標頭檔案
每通常一個 .cc 檔案都有一個對應的 .h 檔案。也有一些常見例外，如單元測試程式碼和只包含 main() 函式的 .cc 檔案。
正確使用標頭檔案可令程式碼在可讀性，檔案大小和效能上大為改觀。
下面的規則將引導你規避使用標頭檔案時的各種陷阱。
1.1。自包含的標頭檔案
TIP
標頭檔案應該能夠自給自足（自包含的，也就是可以作為第一個標頭檔案被引入），以 .h 結尾。至於用來插入文字的檔案，說到底它們並不是標頭檔案，所以以應 .inc 結尾不允許。出分離 -inl.h 標頭檔案的做法。
所有標頭檔案要能夠自給自足。換言之，使用者和重構工具不需要為特別場合而包含額外的標頭檔案。詳言之，一個頭檔案要有 1.2。#define保護，統計包含它所需要的其它標頭檔案，也不要求定義任何特別的符號。
不過有一個例外，即一個檔案並不是自足的，而是作為文字插入到程式碼某處。或者，檔案內容實際上是其它標頭檔案的特定平臺（特定於平臺）擴充套件部分，這些檔案就要用 .inc 副檔名。
如果 .h 檔案聲明瞭一個模板或行內函數，同時也在該檔案加以定義。有用凡是到這些的 .cc 檔案，就得統統包含該標頭檔案，否則程式可能會在構建中連結失敗。不要把這些定義放到分離的 -inl.h 檔案裡（譯者注：過去該規範曾提倡把定義放到-inl.h裡過）。
有個例外：如果某函式模板為所有相關模板引數顯式例項化，或本身就是某類的一個私有成員，它就那麼定義只能在例項化該模板的 .cc 檔案裡。
1.2。#define保護
TIP
所有標頭檔案都應該使用 #define 來防止標頭檔案被多重包含，命名格式當是： <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_
1.3。前置宣告
TIP
儘可能地避免使用前置宣告。使用 #include 所有遊戲需要的標頭檔案即可。
定義：
所謂「前置宣告」（forward declaration）是類，函式和模板的純粹宣告，沒伴隨著其定義。
優點：
前置宣告能夠節省編譯時間，的多餘 #include 會迫使compile-器展開更多的檔案，處理更多的輸入。
前置宣告能夠節省不必要的重新編譯的時間。 #include 使程式碼因為標頭檔案中無關的改動而被重新編譯多次。
缺點：
前置宣告隱藏了依賴關係，標頭檔案改動時，使用者的程式碼會跳過必要的重新編譯過程。
前置宣告可能會被庫的後續更改所破壞。前置宣告函式或模板有時會妨礙標頭檔案開發者變動其API。例如擴大形參型別，加個自帶預設引數的模板形參等等。
前置宣告來自名稱空間 std:: 的符號時，其行為未定義。
很難判斷什麼時候該用前置宣告，時候什麼用該 #include 極端情況下，用前置宣告代替。 includes 甚至都會暗暗地改變程式碼的含義：
// bh：
struct B {};
struct D ： B {}
// good_user.cc：
＃包括 “BH”
void f （B * ）;
void f （void * ）;
void test （D * x ） { f （x ）; } //呼叫f（B *）
如果 #include 被 B 狀語從句： D 的前置宣告替代， test() 就會呼叫 f(void*) 。
前置聲明瞭include 不少來自標頭檔案的符號時，就會比單單一行的 冗長。
僅僅為了能前置宣告而重構程式碼（比如用指標成員代替物件成員）會使程式碼變得更慢更復雜。
結論：
儘量避免前置宣告那些定義在其他專案中的實體。
函式：總是使用 #include。
類模板：優先使用 #include。
至於什麼時候包含標頭檔案，參見 1.5。#include的路徑及順序 。
1.4。行內函數
TIP
只有當函式只有10行甚至更少時才將其定義為行內函數。
定義：
當函式被宣告為行內函數之後，編譯器會將其內聯展開，而不是按通常的函式呼叫機制進行呼叫。
優點：
只要內聯的函式體小小，內聯該函式可以令目的碼更加高效。對於存取函式以及其它函式體比較短，性能關鍵的函式，鼓勵使用內聯。
缺點：
濫用內聯將導致程式變得更慢。內聯可能使目的碼量或增或減，這取決於行內函數的大小。內聯非常短小的存取函式通常會減少程式碼大小，但內聯一個相當大的函式將戲劇性的增加程式碼大小。現代處理器由於更好的利用了指令快取，小巧的程式碼往往執行更快。
結論：
一個較為合理的經驗準則是，不要內聯超過10行的函式。謹謹對待解構函式，解構函式往往比其表面看起來要更長，因為有隱含的成員和基類解構函式被呼叫！
另一個實用的經驗準則：內聯那些包含迴圈或 switch 語句的函式常常是得不償失（除非在大多數情況下，這些迴圈或 switch 語句從不被執行）。
有些函式即使宣告為內聯的也不一定會被編譯器內聯，這點很重要; 比如虛擬函式和遞迴函式就不會被正常內聯。通常，遞迴函式不應該宣告成行內函數。（YuleFox注：遞迴呼叫堆疊的展開並不像迴圈那麼簡單，比如遞進層數在編譯時可能是未知的，大多數編譯器都不支援內聯遞迴函式）。虛擬函式內聯的主要原因是想把它的函式體放在類定義內，為了圖個方便，抑或是當作檔案描述其行為，比如精短的存取函式。
1.5。 #include 的路徑及順序
TIP
使用標準的標頭檔案包含順序可增強可讀性，避免隱藏依賴：相關標頭檔案，C庫，C ++庫，其他庫的 .h，本專案內的 .h。
專案內部檔案應按照專案原始碼目錄樹結構排列，避免使用UNIX特殊的快捷目錄 .（當前目錄）或 .. （上級目錄）。例如， google-awesome-project/src/base/logging.h 應該按如下方式包含：
#include “base / logging.h”
又如， dir/foo.cc 或 dir/foo_test.cc 的主要作用英文的英文實現或測試 dir2/foo2.h 的功能， foo.cc 中包含標頭檔案的次序如下：
dir2/foo2.h （優先位置，詳情如下）
C系統檔案
C ++系統檔案
庫其他的 .h 檔案
專案本。內 .h 檔案
優先這種順序的排序保證當 dir2/foo2.h 遺漏某些必要的庫時， dir/foo.cc 或 dir/foo_test.cc 的構建會立刻中止。因此這一條規則保證維護這些檔案的人們首先看到構建中止的訊息而不是維護其他包的人們。
dir/foo.cc 和 dir2/foo2.h 通常位於同一目錄下（如 base/basictypes_unittest.cc 和 base/basictypes.h），但也可放在不同目錄下。
按字母順序分別對每種型別的標頭檔案進行二次排序是不錯的主意。注意較老的程式碼可不符合這條規則，要在方便的時候改正它們。
您所依賴的符號（符號）被哪些標頭檔案所定義，您就應該包含（包括）哪些標頭檔案，前置宣告 （向前宣告）情況除外。您比如要用到 bar.h 中的某個符號，哪怕您所包含的 foo.h 已經包含了 bar.h，也照樣得包含 bar.h，除非foo.h 有明確 說明它會自動向您提供 bar.h 中符號。不過，凡是cc檔案所對應的「相關標頭檔案」已經包含的，就不用再重複包含進其cc檔案裡面了，就像 foo.cc 只包含 foo.h就夠了，不用再管後者所包含的其它內容。
舉#include “foo / public / fooserver.h”//優先位置
#include “foo / public / bar.h”例如， google-awesome-project/src/foo/internal/fooserver.cc 包含次序如下：
4.函式
4.1。引數順序
總述
函式的引數順序為：輸入引數在先，後跟輸出引數。
說明
C / C ++中的函式引數或者是函式的輸入，或者是函式的輸出，或兼而有之。輸入引數通常是值參或 const 引用，輸出引數或輸入/輸出引數則一般為非 const 指標。在排列引數順序時，將所有的輸入引數置於輸出引數之前。特別要注意，在加入新引數時不要因為它們是新引數就置於引數列表最後，而是仍然要按照前述的規則，即將新的輸入引數也置於輸出引數之前。
這並非一個硬性規定。輸入/輸出引數（通常是類或結構體）讓這個問題變得複雜。並且，有時候為了其他函式保持一致，你可能不得不不所有變通。
4.2。編寫簡短函式
總述
我們傾向於編寫簡短，凝練的函式。
說明
我們承認長函式有時是合理的，因此並不硬限制函式的長度。如果函式超過40行，可以思索一下能不能在不影響程式結構的前提下對其進行分割。
即使一個長函式現在工作的非常好，一旦有人對其修改，有可能出現新的問題，甚至導致難以發現的錯誤。使函式儘量簡短，以便於他在他人閱讀和修改程式碼。
在處理程式碼時，你可能會發現複雜的長函式。不要害怕修改現有程式碼：如果證實這些程式碼使用/除錯起來很困難，或者你只需要使用其中的一小段程式碼，考慮將其分割為更加簡短並易於管理的若干函式。
4.3。引用引數
總述
所有按引用傳遞的引數必須加上 const。
定義
在C語言中，如果函式需要修改變數的值，引數必須為指標，如 。在C ++中，函式還可以宣告為引用引數： 。int foo(int *pval)int foo(int &val)
優點
引用定義引數可以防止出現 (*pval)++ 這樣醜陋的程式碼。引用引數對於拷貝建構函式這樣的應用也是必需的。同時也更明確地不接受空指標。
缺點
容易引起誤解，因為引用在語法上是值變數卻擁有指標的語義。
結論
函式引數列表中，所有引用引數都必須是 const：
void Foo （const string ＆in ， string * out ）;
事實上這在Google Code是一個硬性約定：輸入引數是值參或 const 引用，輸出引數為指標。輸入引數可以是 const 指標，但決不能是非 const 引用引數，除非特殊要求，比如 swap()。
有時候，在輸入形參中用針指 比 更明智。比如：const T*const T&
可能會傳遞空指標。
函式要把指標或對地址的引用賦值給輸入形參。
總而言之，大多時候輸入形參往往是 。用若 則說明輸入側另有處理。所以若要使用 ，則應給出相應的理由，否則會使讀者感到迷惑。const T&const T*const T*
4.4。函式過載
總述
若要使用函式過載，則必須能讓讀者一看呼叫點就胸有成竹，而不用花心思猜測呼叫的過載函式到底是哪一種。這一規則也適用於建構函式。
定義
你可以編寫一個引數型別為 的函式，然後用另一個引數型別為 的函式對其進行過載：const string&const char*
class MyClass {
public ：
void Analyze （const string ＆text ）;
void 分析（const char * text ， size_t textlen ）;
};
優點
通過過載引數不同的同名函式，可以令程式碼更直觀。模板化程式碼需要過載，這同時也能為使用者帶來便利。
缺點
如果函式單靠不同的引數型別而過載（acgtyrant注：這意味著引數數量不變），讀者就得十分熟悉C ++五花八門的匹配規則，以瞭解匹配過程具體到底如何。另外，如果派生類只過載了某個函式的部分變體，繼承語義就容易令人困惑。
結論
如果打算過載一個函式，可以試試改在函式名里加引數資訊。例如，用 AppendString()和 AppendInt() 等，而不是一口氣過載多個 Append()。如果過載函式的目的是為了支援不同數量的同一型別引數，則優先考慮使用 std::vector 以便使用者可以用 列表初始化指定引數。
4.5。預設引數
總述
只允許在非虛擬函式中使用預設引數，且必須保證預設引數的值始終一致。引數預設與 函式過載 遵循同樣的規則。一般情況下建議使用函式過載，尤其是在預設函式帶來的可讀性提升不能彌補下文中所提到的缺點的情況下。
優點
有些函式一般情況下使用預設引數，但有時需要又使用非預設的引數。預設引數為這樣的情形提供了便利，使程式設計師不需要為了極少的例外情況編寫大量的函式。和函式過載相比，預設引數的語法更簡潔明瞭，減少了大量的樣板程式碼，也更好地區別了“必要引數”和“可選引數”。
缺點
預設引數實際上是函式過載語義的另一種實現方式，因此所有 不應當使用函式過載的理由 也都適用於預設引數。
虛擬函式呼叫的預設引數取決於目標物件的靜態型別，此時無法保證給定函式的所有過載宣告的都是同樣的預設引數。
預設引數是在每個呼叫點都要進行重新求值的，這會造成生成的程式碼迅速膨脹。作為讀者，一般來說也更希望預設的引數在宣告時就已經被固定了，而不是在每次呼叫時都可能會有不同的取值。
預設引數會干擾函式指標，導致函式簽名與呼叫點的簽名不一致。而函式過載不會導致這樣的問題。
結論
對於虛擬函式，不允許使用預設引數，因為在虛擬函式中預設引數不一定能正常工作。如果在每個呼叫點預設引數的值都有可能不同，在這種情況下預設函式也不允許使用。（例如，不要寫像 這樣的程式碼。）void f(int n = counter++);
在其他情況下，如果預設引數對可讀性的提升遠遠超過了以上提及的缺點的話，可以使用預設引數。如果仍有疑惑，就使用函式過載。
4.6。函式返回型別後置語法
總述
只有在常規寫法（返回型別前置）不便於書寫或不便於閱讀時使用返回型別後置語法。
定義
C ++現在允許兩種不同的函式宣告方式。以往的寫法是將返回型別置於函式名之前。例如：
int foo （int x ）;
C ++ 11引入了這一新的形式。現在可以在函式名前使用 auto 關鍵字，在引數列表之後後置返回型別。例如：
auto foo （int x ） - > int ;
後置返回型別為函式作用域。對於像 int 這樣簡單的型別，兩種寫法沒有區別。但對於複雜的情況，例如類域中的型別宣告或者以函式引數的形式書寫的型別，寫法的不同會造成區別。
優點
後置返回型別是顯式地指定 Lambda表示式 的返回值的唯一方式。某些情況下，編譯器可以自動推匯出Lambda表示式的返回型別，但並不是在所有的情況下都能實現。即使編譯器能夠自動推導，顯式地指定返回型別也能讓讀者更明瞭。
有時在已經出現了的函式引數列表之後指定返回型別，能夠讓書寫更簡單，也更易讀，尤其是在返回型別依賴於模板引數時。例如：
template < class T ， class U > auto add （T t ， U u ） - > decltype （t + u ）;
對比下面的例子：
template < class T ， class U > decltype （declval < T ＆> （） + declval < U ＆gt ;） add （T t ， U u ）;
缺點
後置返回型別相對來說是非常新的語法，而且在C和Java中都沒有相似的寫法，因此可能對讀者來說比較陌生。
在已有的程式碼中有大量的函式宣告，你不可能把它們都用新的語法重寫一遍。因此實際的做法只能是使用舊的語法或者新舊混用。在這種情況下，只使用一種版本是相對來說更規整的形式。
結論
在大部分情況下，應當繼續使用以往的函式宣告寫法，即將返回型別置於函式名前。只有在必要的時候（如Lambda表示式）或者使用後置語法能夠簡化書寫並且提高易讀性的時候才使用新的返回型別後置語法。但是後一種情況一般來說是很少見的，大部分時候都出現在相當複雜的模板程式碼中，而多數情況下不鼓勵寫這樣 複雜的模板程式碼。
7.命名約定
最重要的一致性規則是命名管理。命名的風格能讓我們在不需要去查詢型別宣告的條件下快速地瞭解某個名字代表的含義：型別，變數，函式，常量，巨集，等等，甚至。我們大腦中的模式匹配引擎非常依賴這些命名規則。
命名規則具有一定隨意性，但相比按個人喜好命名，一致性更重要，所以無論你認為它們是否重要，規則總歸是規則。
7.1。通用命名規則
總述
函式命名，變數命名，檔案命名要有描述性; 少用縮寫。
說明
儘可能使用描述性的命名，別心疼空間，畢竟相比之下讓程式碼易於新讀者理解更重要。不要用只有專案開發者能理解的縮寫，也不要通過砍掉幾個字母來縮寫單詞。
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 ; //刪減了若干字母。
注意，一些特定的廣為人知的縮寫是允許的，例如用 i 表示迭代變數和用 T 表示模板引數。
模板引數的命名應當遵循對應的分類：型別模板引數應當遵循 型別命名 的規則，而非型別模板應當 遵循變數命名 的規則。
7.2。檔案命名
總述
檔名要全部小寫，可以包含下劃線（_）或連-字元（），依照專案的約定。如果沒有約定，那麼“ _” 更好。
說明
可接受的檔案命名示例：
my_useful_class.cc
my-useful-class.cc
myusefulclass.cc
myusefulclass_test.cc // _unittest 狀語從句： _regtest 已棄用。
C ++檔案要以 .cc 結尾，標頭檔案以 .h 結尾。專門插入文字的檔案則以 .inc 結尾，參見 標頭檔案自足。
不要使用已經存在於 /usr/include 下的檔名（Yang.Y注：即編譯器搜尋系統標頭檔案的路徑），如 db.h。
通常應儘量讓檔名更加明確。 http_server_logs.h 就比 logs.h 要好。定義類時檔名一般成對出現，如 foo_bar.h 和 foo_bar.cc，對應於類 FooBar。
聯內必須函式放在 .h 檔案中。如果行內函數比較短，就直接放在 .h 中。
7.3。型別命名
總述
型別名稱的每個單詞首字母均大寫，不包含下劃線： MyExcitingClass， MyExcitingEnum。
說明
所有型別命名 - 類，結構體，型別定義（typedef），列舉，型別模板引數 - 均使用相同約定，即以大寫字母開始，每個單詞首字母均大寫，不包含下劃線。例如：
//類和結構體
類 UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...
//型別定義
typedef hash_map < UrlTableProperties * ， string > PropertiesMap ;
//使用別名
使用 PropertiesMap = hash_map < UrlTableProperties * ， string > ;
//列舉
enum UrlTableErrors { ...
7.4。變數命名
總述
變數（包括函式引數）和資料成員名一律小寫，單詞之間用下劃線連線。類的成員變數以下劃線結尾，但結構體的就不用，如： a_local_variable， a_struct_data_member， a_class_data_member_。
說明
普通變數命名
舉例：
字串 table_name ; //好 - 用下劃線。
字串 表名; //好 - 全小寫。
字串 tableName ; //差 - 混合大小寫
類資料成員
不管是靜態的還是非靜態的，類資料成員都可以和普通變數一樣，但要接下劃線。
類 TableInfo {
...
private ：
string table_name_ ; //好 - 後加下劃線。
字串 tablename_ ; //好。
靜態 池< TableInfo > * pool_ ; //好。
};
結構體變數
不管是靜態的還是非靜態的，結構體資料成員都可以和普通變數一樣，不用像類那樣接下劃線：
struct UrlTableProperties {
string name ;
int num_entries ;
靜態 池< UrlTableProperties > * 池;
};
結構體與類的使用討論，參考 結構體與類。
7.5。常量命名
總述
宣告為 constexpr 或 const 的變數，或在程式執行期間其值始始保持不變的，命名時以“k”開頭，大小寫混合。例如：
const int kDaysInAWeek = 7 ;
說明
所有具有靜態儲存型別的變數（例如靜態變數或全域性變數，參見 儲存型別）都應當以此方式命名。對於其他儲存型別的變數，如自動變數等，這條規則是可選的。如果不採用這條規則，就按照一般的變數命名規則。
7.7。函式命名
總述
常規函式使用大小寫混合，取值和設值函式則要求與變數名匹配： MyExcitingFunction()， MyExcitingMethod()， my_exciting_member_variable()， set_my_exciting_member_variable()。
說明
一般來說，函式名的每個單詞首字母大寫（即“駝峰變數名”或“帕斯卡變數名”），沒有下劃線。對於首字母縮寫的單詞，更傾向於將它們視作一個單詞進行首字母大寫（例如，寫作 StartRpc() 而非 StartRPC()）。
AddTableEntry （）
DeleteUrl （）
OpenFileOrDie （）
（同樣的命名規則同時適用於類作用域和名稱空間作用域的常量，因為它們是作為API的一部分暴露對外的，因此應當讓它們看起來像是一個函式，因為在這時，它們實際上是一個物件而非函式的這一事實對外不過是一個無關緊要的實現細節。）
取值和設值函式的命名與變數一致。一般來說它們的名稱與實際的成員變數對應，但並不強制要求。例如 與 。int count()void set_count(int count)
7.7。名稱空間命名
總述
名稱空間以小寫字母命名。最高階名稱空間的名字取決於專案名稱。要注意避免巢狀名稱空間的名字之間和常見的頂級名稱空間的名字之間發生衝突。
頂級名稱空間的名稱應當是專案名或者是該名稱空間中的程式碼所屬的團隊的名字。名稱空間中的程式碼，應當存放於和名稱空間的名字匹配的資料夾或其子資料夾中。
注意 不使用縮寫作為名稱 的規則同樣適用於名稱空間。名稱空間中的程式碼極少需要涉及名稱空間的名稱，因此沒有必要在名稱空間中使用縮寫。
要避免巢狀的名稱空間與常見的頂級名稱空間發生名稱衝突。由於名稱查詢規則的存在，名稱空間之間的衝突完全有可能導致編譯失敗。尤其是，不要建立巢狀的 std 名稱空間。建議使用更獨特的專案識別符號（websearch::index， websearch::index_util）而非常見的極易發生衝突的名稱（比如 websearch::util）。
對於 internal 名稱空間，要當心加入到同一 internal 名稱空間的程式碼之間發生衝突（由於內部維護人員通常來自同一團隊，因此常有可能導致衝突）。在這種情況下，請使用檔名以使內部名稱獨一無二（例如對於 frobber.h，使用 websearch::index::frobber_internal）。
7.8。列舉命名
總述
的列舉命名應當狀語從句： 常量 或 巨集 harmony和諧： kEnumName 或是 ENUM_NAME。
說明
的單獨列舉值應該優先採用 常量 的命名方式。但 巨集 方式的命名也。可以接受。列舉名 UrlTableErrors （以及 AlternateUrlTableErrors）是型別，所以要用大小寫混合的方式。
enum UrlTableErrors {
kOK = 0 ，
kErrorOutOfMemory ，
kErrorMalformedInput ，
};
列舉 AlternateUrlTableErrors {
OK = 0 ，
OUT_OF_MEMORY = 1 ，
MALFORMED_INPUT = 2 ，
};
2009年1月之前，我們一直建議採用 巨集 的方式命名列舉值。由於列舉值和巨集之間的命名衝突，直接導致了很多問題。由此，這裡改為優先選擇常量風格的命名方式。新程式碼應該儘可能優先使用常量風格。但是老程式碼沒必要切換到常量風格，除非巨集風格確實會產生編譯期問題。
7.9。巨集命名
總述
你並不打算 使用巨集，對吧？如果你一定要用，像這樣命名： MY_MACRO_THAT_SCARES_SMALL_CHILDREN。
說明
參考 預處理巨集 ; 通常 不應該 使用巨集。如果不得不使用，其命名像列舉命名一樣全部大寫，使用下劃線：
#define ROUND（x）...
#define PI_ROUNDED 3.0
7.10。命名規則的特例
總述
如果你命名的實體與已有C / C ++實體相似，可參考現有命名策略。
bigopen()：函式名，參照 open() 的形式
uint： typedef
bigpos： struct 或 class，參照 pos 的形式
sparse_hash_map：STL型實體; 參照STL命名約定
LONGLONG_MAX：常量，如同 INT_MAX
8.注意
註釋雖然寫起來很痛苦，但對保證程式碼可讀性至關重要。下面的規則描述瞭如何註釋以及在哪兒註釋。當然也要記住：註釋固然很重要，但最好的程式碼應當本身就是文件。有意義的型別名和變數名，要遠勝過要用註釋解釋的含糊不清的名字。
你寫的註釋是給程式碼讀者看的，也就是下一個需要理解你的程式碼的人。所以慷慨些吧，下一個讀者可能就是你！
8.1。註釋風格
總述
使用 // 或 ，統一就好。/* */
說明
// 或 都可以; 但 更 常用。要在如何註釋及註釋風格上確保統一。/* *///
8.2。檔案註釋
總述
在每一個檔案開頭加入版權公告。
檔案註釋描述了該檔案的內容。如果一個檔案只宣告，或實現或測試了一個物件，並且這個物件已經在它的宣告處進行了詳細的註釋，那麼就沒有必要再加上檔案註釋。除此之外的其他檔案都需要檔案註釋。
說明
法律公告和作者資訊
每個檔案都應該包含許可證引用。為專案選擇合適的許可證版本（比如，Apache 2.0，BSD，LGPL，GPL）
如果你對原始作者的檔案做了重大修改，請考慮刪除原作者資訊。
檔案內容
如果一個 .h 檔案聲明瞭多個概念，則檔案註釋應當對檔案的內容做一個大致的說明，同時說明各個概念之間的聯絡。一個一到兩行的檔案註釋就足夠了，對於每個概念的詳細文件應當放在各個概念中，而不是檔案註釋中。
不要在 .h 和 .cc 之間複製註釋，這樣的註釋偏離了註釋的實際意義。
8.3。類註釋
總述
每個類的定義都要附帶一份註釋，描述類的功能和用法，除非它的功能相當明顯。
//遍歷GargantuanTable的內容。
//示例：
// GargantuanTableIterator * iter = table-> NewIterator（）;
// it for（iter-> Seek（“foo”）;！iter-> done（）; iter-> Next（））{
// process（iter-> key（），iter-> value（））;
//}
//刪除它;
類 GargantuanTableIterator {
...
};
說明
類註釋應當為讀者理解如何使用與何時使用類提供足夠的資訊，同時應當提醒讀者在正確使用此類時應當考慮的因素。如果類有任何同步前提，請用文件說明。如果該類的例項可被多執行緒訪問，要特別注意文件說明多執行緒環境下相關的規則和常量使用。
如果你想用一小段程式碼演示這個類的基本用法或通常用法，放在類註釋裡也非常合適。
如果類的宣告和定義分開了（例如分別放在了 .h 和 .cc 檔案中），此時，描述類用法的註釋應當和介面定義放在一起，描述類的操作和實現的註釋應當和實現放在一起。
8.4。函式註釋
總述
函式宣告處的註釋描述函式功能; 定義處的註釋描述函式實現。
說明
函式宣告
基本上每個函式宣告處前都應當加上註釋，描述函式的功能和用途。只有在函式的功能簡單而明顯時才能省略這些註釋（例如，簡單的取值和設值函式）。註釋使用敘述式（“開啟檔案”）而非指令式（“開啟檔案”）; 註釋只是為了描述函式，而不是命令函式做什麼。通常，註釋不會描述函式如何工作。那是函式定義部分的事情。
函式宣告處註釋的內容：
函式的輸入輸出。
對類成員函式而言：函式呼叫期間物件是否需要保持引用引數，是否會釋放這些引數。
函式是否分配了必須由呼叫者釋放的空間。
引數是否可以為空指標。
是否存在函式使用上的效能隱患。
如果函式是可重入的，其同步提提是什麼？
舉例如下：
//返回此表的迭代器。
當迭代器完成時，它是
客戶端的責任//並且一旦
建立
迭代器的GargantuanTable物件被刪除，它就不能使用迭代器。//
//迭代器最初位於表的開始位置。
//
//此方法等同於：
// Iterator * iter = table-> NewIterator（）;
// iter-> Seek（“”）;
//返回iter;
//如果您要立即尋找到
返回的迭代器
中的其他位置，則使用NewIterator（）會更快，並避免額外的查詢。
Iterator * GetIterator （） const;
但也要避免羅羅嗦嗦，或者對顯著易見的內容進行說明。下面的註釋就沒有必要加上“否則返回false”，因為已經暗含其中了：
//如果表不能包含更多條目，則返回true。
bool IsTableFull （）;
註釋函式過載時，註釋的重點應該是函式中被過載的部分，而不是簡單的重複被過載的函式的註釋。多數情況下，函式過載不需要額外的文件，因此也沒有必要加上註釋。
註釋構造/解構函式，切記讀程式碼的人知道構造/解構函式的所有功能，所以“銷燬這一物件”這樣的註釋是沒有意義的。你應該注意的是注意建構函式對引數做了什麼（例如，是否取得指標所有權）以及解構函式清理了什麼。如果都是些無關緊要的內容，直接省掉註釋。解構函式前沒有註釋是很正常的。
函式定義
如果函式的實現過程中用到了很巧妙的方式，那麼在函式定義處應當加上解釋性的註釋。例如，你所使用的程式設計技巧，實現的大致步驟，或解釋如此實現的理由。舉個例子，你可以說明為什麼函式的前半部分要加鎖而後半部分不需要。
不要 從 .h 檔案或其他地方的函式宣告處直接複製註釋。簡要重述函式功能是可以的，但註釋重點要放在如何實現上。
8.5。變數註釋
總述
通常變數名本身足以很好說明變數用途。某些情況下，也需要額外的註釋說明。
說明
類資料成員
每個類資料成員（也叫例項變數或成員變數）都應該用註釋說明用途。如果有非變數的引數（例如特殊值，資料成員之間的關係，生命週期等）不能夠使用型別與變數名明確表達，則應當加上註釋。然而，如果變數型別與變數名已經足夠描述一個變數，那麼就不需要加上註釋。
特別地，如果變數可以接受 NULL 或 -1 等警戒值，須加以說明。比如：
private ：
//用於限制檢查表訪問。-1意味著
//我們還不知道表中有多少個條目。
int num_total_entries_ ;
全域性變數
和資料成員一樣，所有全域性變數也要註釋說明含義及用途，以及作為全域性變數的原因。比如：
//在此迴歸測試中我們經歷的測試用例的總數。
const int kNumTestCases = 6 ;
8.6。實現註釋
總述
對於程式碼中巧妙的，晦澀的，有趣的，重要的地方加以註釋。
說明
程式碼前註釋
巧妙或複雜的程式碼段前要加註釋。比如：
//將結果除以2，考慮到x
//包含來自add的進位。
for （int i = 0 ; i < result - > size （）; i ++ ） {
x = （x << 8 ） + （* result ）[ i ];
（* 結果）[ i ] = x >> 1 ;
x ＆= 1 ;
}
行註釋
比較隱晦的地方要在行尾加入註釋。在行尾空兩格進行註釋。比如：
//如果我們有足夠的記憶體，也可以對資料部分進行mmap。
mmap_budget = max < int64 > （0 ， mmap_budget - index_ - > length （））;
if （mmap_budget > = data_size_ && ！MmapData （mmap_chunk_bytes ， mlock ））
return ; //錯誤已經記錄。
注意，這裡用了兩段註釋分別描述這段程式碼的作用，並提示函式返回錯誤已經被記入日誌。
如果你需要連續進行多行註釋，可以使之對齊獲得更好的可讀性：
DoSomething （）; //在這裡發表評論，以便評論排成一行。
DoSomethingElseThatIsLonger （）; //程式碼和註釋之間有兩個空格。
{ //允許開啟一個新的作用域時，在註釋之前的一個空格
// //因此註釋與下面的註釋和程式碼一起排列。
DoSomethingElse （）; //通常在行註釋之前有兩個空格。
}
std :: vector < string > list {
//支撐列表中的註釋描述下一個元素...
“First item” ，
// ..並且應該適當地對齊。
“第二項” };
做一點事（）; / *對於尾部塊註釋，一個空間可以。* /
函式引數註釋
如果函式引數的意義不明顯，考慮用下面的方式進行彌補：
如果引數是一個字面常量，並且這一常量在多處函式呼叫中被使用，用以推斷它們一致，你應該用一個常量名讓這個約定變得更明顯，並且保證這一約定不會被打破。
考慮更改函式的簽名，讓某個 bool 型別的引數變為 enum 型別，這樣可以讓這個引數的值表達其意義。
如果某個函式有多個配置選項，你可以考慮定義一個類或結構體以儲存所有的選項，並傳入類或結構體的例項。這樣的方法有許多優點，例如這樣的選項可以在呼叫處用變數名引用，這樣就能清晰地表明其意義。同時也減少了函式引數的數量，使得函式呼叫更易讀也易寫。除此之外，以這樣的方式，如果你使用其他的選項，就無需對呼叫點進行更改。
用具名變數代替大段而複雜的巢狀表示式。
萬不得已時，才考慮在呼叫點用註釋闡明引數的意義。
比如下面的示例的對比：
//這些論據是什麼？
const DecimalNumber product = CalculateProduct （values ， 7 ， false ， nullptr ）;
和
ProductOptions 選項;
選項。set_precision_decimals （7 ）;
選項。set_use_cache （ProductOptions :: kDontUseCache ）;
const DecimalNumber product =
CalculateProduct （values ， options ， / * completion_callback = * / nullptr ）;
哪個更清晰一目瞭然。
不允許的行為
不要描述顯而易見的現象， 永遠不要 用自然語言翻譯程式碼作為註釋，除非即使對深入理解C ++的讀者來說程式碼的行為都是不明顯的。要假設讀程式碼的人C ++水平比你高，即便他/她可能不知道你的用意：
你所提供的註釋應當解釋程式碼 為什麼 要這麼做和程式碼的目的，或者最好是讓程式碼自文件化。
比較這樣的註釋：
//在向量中查詢元素。< - 差：這太明顯了！
自動 ITER = STD :: 找到（v 。開始（）， v 。端（）， 元素）;
如果 （ITER =！ v 。端（）） {
過程（元件）;
}
和這樣的註釋：
//處理“元素”，除非它已經被處理。
自動 ITER = STD :: 找到（v 。開始（）， v 。端（）， 元素）;
如果 （ITER =！ v 。端（）） {
過程（元件）;
}
自文件化的程式碼根本就不需要註釋。上面例子中的註釋對下面的程式碼來說就是毫無必要的：
if （！IsAlreadyProcessed （element ）） {
Process （element ）;
}
8.8。標點，拼寫和語法
總述
注意標點，拼寫和語法; 寫的好的註釋比差的要易讀的多。
說明
註釋的通常寫法是包含正確大小寫和結尾句號的完整敘述性語句。大多數情況下，完整的句子比句子片段可讀性更高。短一點的註釋，比如程式碼行尾註釋，可以隨意點，但依然要注意風格的一致性。
雖然被別人指出該用分號時卻用了逗號多少有些尷尬，但清晰易讀的程式碼還是很重要的。正確的標點，拼寫和語法對此會有很大幫助。
8.8。TODO註釋
總述
對那些臨時的，短期的解決方案，或已經夠好，但仍不完美的程式碼使用 TODO 註釋。
TODO 注意要使用全大寫的字串 TODO，在隨後的圓括號裡寫上你的名字，郵件地址，bug ID，或其它身份標識和與這一 TODO 相關的問題。主要目的是讓添加註釋的人（也是可以請求提供更多細節的人）可根據規範的 TODO 格式進行查詢。新增 TODO 註釋並不意味著你要自己來修正，因此當你加上帶有姓名的時候 TODO ，一般都是寫上自己的名字。
// TODO（[email protected]）：這裡使用“*”作為連線運算子。
// TODO（Zeke）將其改為使用關係。
// TODO（錯誤12345）：刪除“最後訪問者”功能
如果加 TODO 是為了在“將來某一天做某事”，可以附上一個非常明確的時間“Fix by November 2005”），或者一個明確的事項（“所有客戶端都可以處理XML響應時刪除此程式碼。”） 。
8.9。棄用註釋
總述
通過棄用註釋（DEPRECATED 評論）以標記某介面點已棄用。
您可以寫上包含全大寫的 DEPRECATED 註釋，以標記某介面為棄用狀態。註釋可以放在介面宣告前，或者同一行。
在DEPRECATED 一詞後，在 括號中留下您的名字，郵箱地址以及其他身份標識。
棄用註釋應當包涵簡短而清晰的指引，以幫助其他人修復其呼叫點。在C ++中，你可以將一個棄用函式改造成一個行內函數，這一函式將呼叫新的介面。
DEPRECATED 僅僅標記介面為並 不允許大家不約而同地棄用，您還得親自主動修正呼叫點（callsites），或是找個幫手。
修正好的程式碼應該不會再涉及棄用介面點了，著實改用新介面點。如果您不知從何下手，可以找標記棄用註釋的當事人一起商量。
9.格式
每個人都可能有自己的程式碼風格和格式，但如果一個專案中的所有人都遵循同一風格的話，這個專案就能更順利地進行。每個人未必能同意下述的每一處格式規則，而且其中的不少規則需要一定時間的適應，但整個專案服從統一的程式設計風格是很重要的，只有這樣才能讓所有人輕鬆地閱讀和理解程式碼。
為了幫助你正確的格式化程式碼，我們寫了一個 emacs配置檔案。
9.1。行長度
總述
每一行程式碼字元數不超過80。
我們也認識到這條規則是有爭議的，但很多已有程式碼都遵照這一規則，因此我們感覺一致性更重要。
優點
提倡該原則的人認為強迫他們調整編輯器視窗大小是很野蠻的行為。很多人同時並排開幾個程式碼視窗，根本沒有多餘的空間拉伸視窗。大家都把視窗最大尺寸加以限定，並且80列寬是傳統標準。那麼為什麼要改變呢？
缺點
反對該原則的人則認為更寬的程式碼行更易閱讀。80列的限制是上個世紀60年代的大型機的古板缺陷; 現代裝置具有更寬的顯示屏，可以很輕鬆地顯示更多程式碼。
結論
80個字元是最大值。
如果無法在不傷害易讀性的條件下進行斷行，那麼註釋行可以超過80個字元，這樣可以方便複製貼上。例如，帶有命令示例或URL的行可以超過80個字元。
長所有遊戲的路徑 #include 語句可以超出80列。
檔案頭保護 可以無視該原則。
9.2。非ASCII字元
總述
儘量不使用非ASCII字元，使用時必須使用UTF-8編碼。
說明
即使是英文，也不應將使用者介面的文字硬編碼到原始碼中，因此非ASCII字元應當很少被用到。特殊情況下可以適當包含此類字元。例如，程式碼分析外部資料檔案時，可以適當硬編碼資料檔案中作為分隔符的非ASCII字串; 更常見的是（不需要本地化的）單元測試程式碼可能包含非ASCII字串。此類情況下，應使用UTF-8編碼，因為很多工具都可以理解和處理UTF-8編碼。
十六進位制編碼也可以，能增強可讀性的情況下尤其鼓鼓 - 比如 "\xEF\xBB\xBF"，或者更簡潔地寫作 u8"\uFEFF"，在Unicode中是 零寬度無間斷 的間隔符號，如果不用十六進位制直接放在UTF -8格式的原始檔中，是看不到的。
（Yang.Y注： "\xEF\xBB\xBF" 通常用作帶編碼標記的UTF-8）
使用 u8 字首把帶 uXXXX 轉義序列的字串字面值編碼成UTF-8。不要用在本身就帶UTF-8字元的字串字面值上，因為如果編譯器不把原始碼識別成UTF-8，輸出就會出錯。
別用C ++ 11的 char16_t 和 char32_t，它們和UTF-8文字沒有關係， wchar_t 同理，除非你寫的程式碼要呼叫Windows API，後者廣泛使用了 wchar_t。
9.3。空格還是製表位
總述
只使用空格，每次縮排2個空格。
說明
我們使用空格縮排。不要在程式碼中使用製表符。你應該設定編輯器將製表符轉為空格。
9.4。函式宣告與定義
總述
返回型別和函式名在同一行，引數也儘量放在同一行，如果放不下就對形參分行，分行方式與 函式呼叫 一致。
說明
函式看上去像這樣：
ReturnType ClassName :: FunctionName （Type par_name1 ， Type par_name2 ） {
DoSomething （）;
...
}
如果同一行文字太多，放不下所有引數：
ReturnType ClassName :: ReallyLongFunctionName （型別 par_name1 ， 型別 par_name2 ，
型別 par_name3 ） {
DoSomething （）;
...
}
甚至連第一個引數都放不下：
ReturnType LongClassName :: ReallyReallyReallyLongFunctionName （
Type par_name1 ， // 4 space indent
Type par_name2 ，
Type par_name3 ） {
DoSomething （）; // 2空格縮排
...
}
注意以下幾點：
使用好的引數名。
只有引數未被使用或者其用途非常明顯時，才能省略引數名。
如果返回型別和函式名在一行放不下，分行。
如果返回型別與函式宣告或定義分行了，不要縮排。
左圓括號總是和函式名在同一行。
函式名和左圓括號間永遠沒有空格。
圓括號與引數間沒有空格。
左大括號總在最後一個引數同一行的末尾處，不另起新行。
右大括號總是單獨位於函式最後一行，或者與左大括號同一行。
右圓括號和左大括號間總是有一個空格。
所有形參應儘可能對齊。
預設縮排為2個空格。
換行後的引數保持4個空格的縮排。
未被使用的引數，或者根據上下文很容易看出其用途的引數，可以省略引數名：
類 美孚 {
公共：
美孚（富&& ）;
Foo （const Foo ＆）;
Foo ＆ operator = （Foo && ）;
Foo ＆ operator = （const Foo ＆）;
};
未被使用的引數如果其用途不明顯的話，在函式定義處將引數名註釋起來：
class Shape {
public ：
virtual void Rotate （double radians ） = 0 ;
};
class Circle : public Shape {
public:
void Rotate(double radians) override;
};
void Circle::Rotate(double /*radians*/) {}
// 差 - 如果將來有人要實現, 很難猜出變數的作用.
void Circle::Rotate(double) {}
屬性, 和展開為屬性的巨集, 寫在函式宣告或定義的最前面, 即返回型別之前:
MUST_USE_RESULT bool IsOK();
9.5. Lambda 表示式
總述
Lambda 表示式對形參和函式體的格式化和其他函式一致; 捕獲列表同理, 表項用逗號隔開.
說明
若用引用捕獲, 在變數名和 & 之間不留空格.
int x = 0;
auto add_to_x = [&x](int n) { x += n; };
短 lambda 就寫得和行內函數一樣.
std::set<int> blacklist = {7, 8, 9};
std::vector<int> digits = {3, 9, 1, 8, 4, 7, 1};
digits.erase(std::remove_if(digits.begin(), digits.end(), [&黑名單]（詮釋 我） {
返回 黑名單。找到（i ） ！= 黑名單。end （）;
}），
數字。end （））;
9.6。函式呼叫
總述
要麼一行寫完函式呼叫，要麼在圓括號裡對引數分行，要麼引數另起一行且縮排四格。如果沒有其它顧慮的話，儘可能精簡行數，比如把多個引數適當地放在同一行裡。
說明
函式呼叫遵循如下形式：
bool retval = DoSomething （argument1 ， argument2 ， argument3 ）;
如果同一行放不下，可斷為多行，後面每一行都和第一個實參對齊，左圓括號後和右圓括號前不要留空格：
bool retval = DoSomething （averyveryveryverylongargument1 ，
argument2 ， argument3 ）;
引數也可以放在次行，縮排四格：
如果 （...） {
...
...
if （...） {
DoSomething （
argument1 ， argument2 ， // 4空格縮排
argument3 ， argument4 ）;
}
把多個引數放在同一行以減少函式呼叫所需的行數，除非影響到可讀性。有人認為把每個引數都獨立成行，不僅更好讀，而且方便編輯引數。不過，比起所謂的引數編輯，我們更看重可讀性，且後者比較好辦：
如果一些引數本身就是略複雜的表示式，且降低了可讀性，那麼可以直接建立臨時變數描述該表示式，並傳遞給函式：
int my_heuristic = scores[x] * y + bases[x];
bool retval = DoSomething(my_heuristic, x, y, z);
或者放著不管, 補充上註釋：
bool retval = DoSomething(scores[x] * y + bases[x], // Score heuristic.
x, y, z);
如果某引數獨立成行, 對可讀性更有幫助的話, 那也可以如此做. 引數的格式處理應當以可讀性而非其他作為最重要的原則.
此外, 如果一系列引數本身就有一定的結構, 可以酌情地按其結構來決定引數格式：
//通過3x3矩陣轉換小部件。
my_widget 。變換（x1 ， x2 ， x3 ，
y1 ， y2 ， y3 ，
z1 ， z2 ， z3 ）;
9.7。列表初始化格式
總述
您平時怎麼格式化函式呼叫，就怎麼格式化 列表初始化。
說明
如果列表初始化伴隨著名字，比如型別或變數名，格式化時將將名稱檢視函式呼叫名， {}檢視函式呼叫的括號。如果沒有名字，就視作名字長度為零。
//一行列表初始化示範。
返回 { foo ， bar };
functioncall （{ foo ， bar }）;
pair < int ， int > p { foo ， bar };
//當不得不行時。
SomeFunction （
{ “在{” } 之前假定一個零長度的名字，//假設在{前有長度為零的名字
。some_other_function_parameter ）;
SomeType 變數{
some ， other ， values ，
{ “假設在{” } 之前有一個零長度的名字，//假設在{前有長度為零的名字。
SomeOtherType {
“非常長的字串需要周圍的中斷。” ， //非常長的字串，前後都需要斷行。
一些， 其它 的值}，
SomeOtherType { “略短字串” ， //稍短的字串。
一些， 其它， 值}};
SomeType 變數{
“這太長了，無法將所有內容放在一行中” }; //字串過長，因此無法放在同一行。
MyType m = { //注意了，您可以在{前斷行。
superlongvariablename1 ，
superlongvariablename2 ，
{ short ， interior ， list }，
{ interiorwrappinglist ，
interiorwrappinglist2 }};
9.9。條件語句
總述
傾向於不在圓括號內使用空格。關鍵字 if 狀語從句： else 另起一行。
說明
對基本條件語句有兩種可以接受的格式。一種在圓括號和條件之間有空格，另一種沒有。
最常見的是沒有空格的格式。哪一種都可以，最重要的是 保持一致。如果你是在修改一個檔案，參考當前已有格式。如果是寫新的程式碼，請參考目錄下或專案中的其它檔案。還在猶豫的話，就不要加空格了。
if （condition ） { //圓括號裡沒有空格。
... // 2空格縮排。
} else if （...） { // else與if的右括號同一行。
...
} 其他 {
...
}
如果你更喜歡在圓括號內部加空格：
if （ condition ） { //圓括號與空格緊鄰 - 不常見
... // 2空格縮排。
} else { // else與if的右括號同一行。
...
}
所有注意下情況 if 狀語從句：左圓括號間都有個空格。右圓括號和左大括號之間也要有個空格：
if （condition ） //差 - IF後面沒空格。
if （condition ）{ //差 - {前面沒空格。
if （condition ）{ //變本加厲地差。
if （condition ） { //好 - IF和{都與空格緊鄰。
如果能增強可讀性，簡短的條件語句允許寫在同一行。當只有簡單語句並且沒有使用 else [主語]時使用：
if （x == kFoo ） 返回 新的 Foo （）;
if （x == kBar ） 返回 新的 Bar （）;
如果有語句 else 分支則不允許：
//不允許 - 當有ELSE分支時如塊塊寫在同一行
if （x ） DoThis （）;
其他 DoThat （）;
通常，單行語句不需要使用大括號，如果你喜歡用也沒問題; 複雜的條件或迴圈語句用大括號可讀性會更好。有也。專案一些要求 if 必須總是使用大括號：
如果 （條件）
DoSomething （）; // 2空格縮排。
if （condition ） {
DoSomething （）; // 2空格縮排。
}
但如果語句中 if-else 某個分支使用了大括號的話，其它分支也必須使用：
//不可以這樣子 - 如果有大括號ELSE卻沒有。
if （condition ） {
foo ;
} else
bar ;
//不可以這樣子 - ELSE有大括號IF卻沒有。
如果 （條件）
foo ;
else {
bar ;
}
//只要其中一個分支用了大括號，兩個分支都要用上大括號。
if （condition ） {
foo ;
} else {
bar ;
}
9.9。迴圈和開關選擇語句
總述
switch 語句可以使用大括號分段，以表明cases之間不是連在一起的。在單語句迴圈裡，括號可用可不用。迴圈空應行業釋義體育使用 {} 或 continue。
說明
switch 語句中的 case 塊可以使用大括號也可以不用，取決於你的個人喜好。如果用的話，要按照下文所述的方法。
如果有不滿足 case 條件的列舉值， switch 應該default 總是包含一個 匹配（如果有輸入值沒有case去處理，編譯器將給出警告）。如果 default 應該永遠執行不到，簡單的加條 assert：
switch （var ） {
case 0 ： { // 2空格縮排
... // 4空格縮排
break ;
}
案例 1 ： {
...
break ;
}
default ： {
assert （false ）;
}
}
在單語句迴圈裡，括號可用可不用：
for （int i = 0 ; i < kSomeNumber ; ++ i ）
printf （“我愛你\ n ” ）;
for （int i = 0 ; i < kSomeNumber ; ++ i ） {
printf （“我拿回來\ n ” ）;
}
空迴圈體應使用 {} 或 continue，而不是一個簡單的分號。
while （condition ） {
//反覆迴圈直到條件失效。
}
for （int i = 0 ; i < kSomeNumber ; ++ i ） {} //可 - 空迴圈體。
同時 （條件） 繼續; //可 - contunue表明沒有邏輯。
while （condition ）; //差 - 看起來僅僅只是while / loop的部分之一。
9.10。指標和引用表示式
總述
句點或箭頭前後不要有空格。指標/地址操作符（）之後不能有空格。*, &
說明
下面是指標和引用表示式的正確使用範例：
x = * p ;
p = ＆x ;
x = r 。y ;
x = r - > y ;
注意：
在訪問成員時，句點或箭頭前後沒有空格。
操作指標符 * 或 & 後沒有空格。
在宣告指標變數或引數時，星號與型別或變數名緊挨都可以：
//好，空格前置。
char * c ;
const string ＆str ;
//好，空格後置。
char * c ;
const string ＆ str ;
int x ， * y ; //不允許 - 在多重宣告中不能使用＆或*
char * c ; //差 - *兩邊都有空格
const string ＆ str ; //差 - ＆兩邊都有空格。
在單個檔案內要保持風格一致，所以，如果是修改現有檔案，要遵照該檔案的風格。
9.11。布林表示式
總述
如果一個布林表示式超過 標準行寬，斷行方式要統一一下。
說明
下例中，邏輯與（&&）操作符總位於行尾：
if （this_one_thing > this_other_thing &&
a_third_thing == a_fourth_thing &&
yet_another && last_one ） {
...
}
注意，上例的邏輯與（&&）操作符均位於行尾。這個格式在Google裡很常見，雖然把所有操作符放在開頭也可以。可以考慮額外插入圓括號，合理使用的話對增強可讀性是很有幫助的。此外，直接用符號形式的操作符，比如 && 和 ~，不要用詞語形式的 and 和 compl。
9.12。函式返回值
總述
在不要 return 表示式里加上非必須的圓括號。
說明
在只有寫 要加上括號的時候才在 裡使用括號。x = exprreturn expr;
返回