風格指引的目標

為什麼會有這份文件？

這邊有幾個核心目標是我們相信這份文件該提供的。這些目標就是構成這些規定的主要原因。藉由提出這些想法，我們希望能夠攤開來討論，並且讓大家理解為什麼會有這些規則，以及某些特別的規定是如何訂定出來的。如果你能了解每個規則是為了甚麼目標而制定，那大家應該也能更容易了解某些規定被丟棄時，有哪些必要的考量以及反論。

這份文件目前我們認為的目標有以下幾點：

一條風格規則所帶來的好處必須大到足夠合理來要求我們的工程師記住它。它的好處是以沒有這份指南的情況下撰寫出的程式碼為準來衡量的。有些規則可能在一些極端不好的程式碼中具有些微的好處，但是這種程式碼一般人不太可能會寫得出來的話，我們就不會寫進這份指引。這個原則解釋了大多數我們沒有撰寫的規則，而不是我們會有寫出的規則。舉例來說，goto 違反了下面很多條原則，但是基本上很少人會使用它，因此這份風格指引就不討論它。

並非為了撰寫者，而是為了讀者來優化

我們預計我們的程式碼庫 (以及大多數提交到上面的各個組件) 會持續維護很長的一段時間。因此大多數的時間會花在讀懂它，而非撰寫它。我們明確地選擇優化我們平凡工程師在於讀、維護以及偵錯程式碼的體驗，而非撰寫的便利性。「為讀者留下足跡」正是一種在這個原則之下常見的觀點：如果在一段程式碼中正在發生一些驚喜或者不尋常的事情 (例如：轉移一個指標的所有權)，在這裡留下一些文字上的提示將會非常有用。 (std::unique_ptr 明確地在呼叫處展示了所有權轉移)。

與現有的程式碼保持一致性

在我們程式庫中使用一致的風格讓我們可以專注在其他 (更重要) 的問題。一致性同時也允許了自動化：那些自動幫你調整格式或者 #include 位置的工具只在你的程式碼如它預期般地一致時才能正常運作。在很多狀況下，那些標記為「保持一致性」的規則其實是肇因於「不要想太多，挑一個就好」。在那些情形允許彈性的潛在好處其實大於大家在那邊爭論所花費的時間。

適當時與盡可能大多數的 C++ 社群保持一致性

跟其他組織使用 C++ 的方式保持一致所帶來的價值與在我們自己的程式庫中保持一致性的理由是相同的。如果一個 C++ 標準的特性可以解決一個問題，或者一個寫法被大眾所接受，那就可以當成使用它的理由。然而，有時候這些特性與寫法可能具有某些缺陷，或者並不是我們的程式庫所需要的。在這類情況下，其實更適合限制或者禁止這些特性。在某些情形，如果我們無法感受到特別的好處，或者沒有足夠的價值，比起那些定義在 C++ 標準上的函式庫，我們更喜歡從頭到尾自己撰寫或者直接使用一個第三方的函式庫。

避免令人驚訝或者危險的結構

C++ 有著一些比看起來更令人訝異或者危險的特性。這份風格指引內的部分限制就是為了要避免掉入這種陷阱裡。風格指引對於放棄那些限制具有很高的標準，因為放棄那些規則很有可能會對程式的正確性造成很大的危機。

避免那些讓我們的平凡 C++ 程式設計師認為詭異或者難以維護的結構

有些 C++ 的特性可能一般來說不太適合被使用，因為它們可能常造成一些額外的複雜性。在一些廣泛被使用的程式碼中可能會適合使用特別的語言結構，因為複雜實作所帶來的好處會被廣泛使用這點放大，而且了解這些複雜東西的代價不需要在寫新一塊程式碼時再度付出一次。如果有疑問的話，可以向專案領導詢問是否可以拋棄這類的規則。這對我們的程式庫特別重要，因為程式碼的管理團隊與團隊內部的成員會隨著時間改變：儘管現在正在使用某段程式碼的每個人都了解它，經過了幾年後也不能保證仍會是如此。

在我們的規模下要非常小心

對於一個超過 1 億行以及有著數千位工程師管理的程式庫來說，一個工程師的一些錯誤或者過於簡化的程式碼可能會造成嚴重的後果。舉例來說，要特別注意不能汙染全域命名空間：如果大家都把東西放在全域命名空間的話，對於這種具有數億行程式碼的程式庫來說可能會很難避免命名衝突，並使得程式庫難以維護。

承認必要的優化

雖然有些效能上的優化可能會牴觸這份文件的一些原則，但是對於必要的情況來說還是可接受的。

結論

這份文件的用意在於最大化地提供指引與適當的限制。一如往常，我們的盡量使規則符合常識或看起來順眼。我們特別參考了整個 Google C++ 社群建立起的傳統，而非單獨考量你個人的喜好或者你的團隊。當你看到不尋常的結構時，請善用你的智慧並保持懷疑：沒有限制它們並不代表你可以忽略它們。此時請你自行判斷，如果你不太確定，請不要猶豫，立即詢問你的專案領導來取得意見。