第一章
- 正文前
- 背景
- 目的
- C++版本
1.1．背景
在大多數的Google開源項目中，c++是最主要的開發語言。每個c++程序員都知道，c++語言有很強大的語言特性，但是會導致程序的複雜度提升，在編程的過程中容易出現bug【bug-prune】，並且難以維護【maintain】。
這個文檔通過詳細的描述該做【dos】與不該做【don’t】來進行管理代碼的複雜度。在兼顧代碼庫易維護【manageable】的同時，保證c++程序員在使用c++特性的時候可以得心應手【productively】。
風格【style】,也叫代碼的可讀性【readability】，通常也叫作慣例【conventions】爲了去管理C++代碼，.風格這個詞有些不恰當【misnomer】，因爲這些慣例不僅僅包括源碼文件的格式。
大多數的Google開源項目都會遵循【conform】文檔中描述的風格。
注意：這個文檔不是c++的使用說明書，我們默認讀者對c++足夠熟悉。
1.2. 目的
爲什麼我們需要提供這個文檔？
該文檔是爲了實現一些主要的目標，找到每個單一規則的最原始的出發點。通過對每一個規則適用性【in place】進行詳細的討論，並且得出相應的結論【decision】.如果讀者已經理解了每一個規則所要達到的目的，那麼在規則被遺棄，或者某個規則被改變的時候，讀者也會理解這樣做的意圖。
正如你看到的這個文檔的目的如下：
- 規則應起作用【pull their weight】
遵守規則所帶來的益處需足夠的大，從而可以證明讓所有的工程師去記住這樣的規則是正確的。規則大多數解釋我們不用相應的特性，而不是我們使用相應的特性。比如說goto違反【contravenes】了許多下面相應的規則，但是goto已經被遺棄，因此該文檔將不會考慮討論它。
- 從讀者的角度進行優化
通常期望代碼庫（大多數的子模塊【individual components】提交到代碼庫中）可以使用很長時間.因此大多數時間會去讀相應的code，而不是去寫。我們明確的【explicitly】去選擇優化中等水平的軟件工程師的讀代碼，維護【maintain】，和debug代碼的能力，而不是去優化編寫所述code的難度。“給讀者留下線索”是這些準則的另外一個特別【particularly】目的。當代碼庫中有一段【snippet】精妙或者不尋常【unusual】的code(比如說，指針ownership的轉換)，留下相應的文字提示【textual hints】是非常重要的(std::unique_ptr 表明了ownership轉換的無二義性【unambiguously】)。
- 與現有的code保持一致性
- 在必要的情況下與c++社區保持一致
- 避免奇怪的【surprising】或者危險的設計
- 避免設計出中等engineer難以維護的代碼
- 注意【mindful】代碼庫的大小
- 在必要的情況下需要考慮優化
性能優化【performance optimization】有些時候是必要的，儘管同時會與這個文檔中一些準則會有衝突。
這個文檔的意圖是提供最大的指導，通過合理的約束【reasonable restriction】。通常編程常識或者效果好的習慣【good taste】將被接受並且盛行【prevail】。我們特指的是在整個Google c++社區中的建立的慣例，而不是你的個人或者某個團隊的偏好。如果在使用精妙的【clever】或者不尋常的觀念【constructs】表示懷疑【skeptical】或者不情願【reluctant】，沒有禁止【prohibition】並不認爲是允許【proceed】的，通過自己的判斷，如果還不確信，可以向project leader進行確認得到額外的解釋。
1.3. C++版本
當前code主要面向於c++17,而不是c++2x中的特性。隨着時間的推移，這個文檔面向的c++版本將會進行修改【advance】。
不要去使用非標準的擴展【extensions】。
在使用c++14和c++17中的特性之前，應該認真考慮轉換到其他環境時的便攜性【portability】。