Google編程風(fēng)格指南(三）

4. 函數(shù)

4.1. 參數(shù)順序

總述

函數(shù)的參數(shù)順序?yàn)? 輸入?yún)?shù)在先, 后跟輸出參數(shù).

說明

C/C++ 中的函數(shù)參數(shù)或者是函數(shù)的輸入, 或者是函數(shù)的輸出, 或兼而有之. 輸入?yún)?shù)通常是值參或const引用, 輸出參數(shù)或輸入/輸出參數(shù)則一般為非const指針. 在排列參數(shù)順序時, 將所有的輸入?yún)?shù)置于輸出參數(shù)之前. 特別要注意, 在加入新參數(shù)時不要因?yàn)樗鼈兪切聟?shù)就置于參數(shù)列表最后, 而是仍然要按照前述的規(guī)則, 即將新的輸入?yún)?shù)也置于輸出參數(shù)之前.

這并非一個硬性規(guī)定. 輸入/輸出參數(shù) (通常是類或結(jié)構(gòu)體) 讓這個問題變得復(fù)雜. 并且, 有時候?yàn)榱似渌瘮?shù)保持一致, 你可能不得不有所變通.

4.2. 編寫簡短函數(shù)

總述

我們傾向于編寫簡短, 凝練的函數(shù).

說明

我們承認(rèn)長函數(shù)有時是合理的, 因此并不硬性限制函數(shù)的長度. 如果函數(shù)超過 40 行, 可以思索一下能不能在不影響程序結(jié)構(gòu)的前提下對其進(jìn)行分割.

即使一個長函數(shù)現(xiàn)在工作的非常好, 一旦有人對其修改, 有可能出現(xiàn)新的問題, 甚至導(dǎo)致難以發(fā)現(xiàn)的 bug. 使函數(shù)盡量簡短, 以便于他人閱讀和修改代碼.

在處理代碼時, 你可能會發(fā)現(xiàn)復(fù)雜的長函數(shù). 不要害怕修改現(xiàn)有代碼: 如果證實(shí)這些代碼使用 / 調(diào)試起來很困難, 或者你只需要使用其中的一小段代碼, 考慮將其分割為更加簡短并易于管理的若干函數(shù).

4.3. 引用參數(shù)

總述

所有按引用傳遞的參數(shù)必須加上const.

定義

在 C 語言中, 如果函數(shù)需要修改變量的值, 參數(shù)必須為指針, 如intfoo(int*pval). 在 C++ 中, 函數(shù)還可以聲明為引用參數(shù):intfoo(int&val).

優(yōu)點(diǎn)

定義引用參數(shù)可以防止出現(xiàn)(*pval)++這樣丑陋的代碼. 引用參數(shù)對于拷貝構(gòu)造函數(shù)這樣的應(yīng)用也是必需的. 同時也更明確地不接受空指針.

缺點(diǎn)

容易引起誤解, 因?yàn)橐迷谡Z法上是值變量卻擁有指針的語義.

結(jié)論

函數(shù)參數(shù)列表中, 所有引用參數(shù)都必須是const:

void Foo(const string &in, string *out);

事實(shí)上這在 Google Code 是一個硬性約定: 輸入?yún)?shù)是值參或const引用, 輸出參數(shù)為指針. 輸入?yún)?shù)可以是const指針, 但決不能是非const的引用參數(shù), 除非特殊要求, 比如swap().

有時候, 在輸入形參中用constT*指針比constT&更明智. 比如:

可能會傳遞空指針.

函數(shù)要把指針或?qū)Φ刂返囊觅x值給輸入形參.

總而言之, 大多時候輸入形參往往是constT&. 若用constT*則說明輸入另有處理. 所以若要使用constT*, 則應(yīng)給出相應(yīng)的理由, 否則會使得讀者感到迷惑.

4.4. 函數(shù)重載

總述

若要使用函數(shù)重載, 則必須能讓讀者一看調(diào)用點(diǎn)就胸有成竹, 而不用花心思猜測調(diào)用的重載函數(shù)到底是哪一種. 這一規(guī)則也適用于構(gòu)造函數(shù).

定義

你可以編寫一個參數(shù)類型為conststring&的函數(shù), 然后用另一個參數(shù)類型為constchar*的函數(shù)對其進(jìn)行重載:

class MyClass { public: void Analyze(const string &text); void Analyze(const char *text, size_t textlen);};

優(yōu)點(diǎn)

通過重載參數(shù)不同的同名函數(shù), 可以令代碼更加直觀. 模板化代碼需要重載, 這同時也能為使用者帶來便利.

缺點(diǎn)

如果函數(shù)單靠不同的參數(shù)類型而重載 (acgtyrant 注：這意味著參數(shù)數(shù)量不變), 讀者就得十分熟悉 C++ 五花八門的匹配規(guī)則, 以了解匹配過程具體到底如何. 另外, 如果派生類只重載了某個函數(shù)的部分變體, 繼承語義就容易令人困惑.

結(jié)論

如果打算重載一個函數(shù), 可以試試改在函數(shù)名里加上參數(shù)信息. 例如, 用AppendString()和AppendInt()等, 而不是一口氣重載多個Append(). 如果重載函數(shù)的目的是為了支持不同數(shù)量的同一類型參數(shù), 則優(yōu)先考慮使用std::vector以便使用者可以用列表初始化指定參數(shù).

4.5. 缺省參數(shù)

總述

只允許在非虛函數(shù)中使用缺省參數(shù), 且必須保證缺省參數(shù)的值始終一致. 缺省參數(shù)與函數(shù)重載遵循同樣的規(guī)則. 一般情況下建議使用函數(shù)重載, 尤其是在缺省函數(shù)帶來的可讀性提升不能彌補(bǔ)下文中所提到的缺點(diǎn)的情況下.

優(yōu)點(diǎn)

有些函數(shù)一般情況下使用默認(rèn)參數(shù), 但有時需要又使用非默認(rèn)的參數(shù). 缺省參數(shù)為這樣的情形提供了便利, 使程序員不需要為了極少的例外情況編寫大量的函數(shù). 和函數(shù)重載相比, 缺省參數(shù)的語法更簡潔明了, 減少了大量的樣板代碼, 也更好地區(qū)別了 “必要參數(shù)” 和 “可選參數(shù)”.

缺點(diǎn)

缺省參數(shù)實(shí)際上是函數(shù)重載語義的另一種實(shí)現(xiàn)方式, 因此所有不應(yīng)當(dāng)使用函數(shù)重載的理由也都適用于缺省參數(shù).

虛函數(shù)調(diào)用的缺省參數(shù)取決于目標(biāo)對象的靜態(tài)類型, 此時無法保證給定函數(shù)的所有重載聲明的都是同樣的缺省參數(shù).

缺省參數(shù)是在每個調(diào)用點(diǎn)都要進(jìn)行重新求值的, 這會造成生成的代碼迅速膨脹. 作為讀者, 一般來說也更希望缺省的參數(shù)在聲明時就已經(jīng)被固定了, 而不是在每次調(diào)用時都可能會有不同的取值.

缺省參數(shù)會干擾函數(shù)指針, 導(dǎo)致函數(shù)簽名與調(diào)用點(diǎn)的簽名不一致. 而函數(shù)重載不會導(dǎo)致這樣的問題.

結(jié)論

對于虛函數(shù), 不允許使用缺省參數(shù), 因?yàn)樵谔摵瘮?shù)中缺省參數(shù)不一定能正常工作. 如果在每個調(diào)用點(diǎn)缺省參數(shù)的值都有可能不同, 在這種情況下缺省函數(shù)也不允許使用. (例如, 不要寫像voidf(intn=counter++);這樣的代碼.)

在其他情況下, 如果缺省參數(shù)對可讀性的提升遠(yuǎn)遠(yuǎn)超過了以上提及的缺點(diǎn)的話, 可以使用缺省參數(shù). 如果仍有疑惑, 就使用函數(shù)重載.

4.6. 函數(shù)返回類型后置語法

總述

只有在常規(guī)寫法 (返回類型前置) 不便于書寫或不便于閱讀時使用返回類型后置語法.

定義

C++ 現(xiàn)在允許兩種不同的函數(shù)聲明方式. 以往的寫法是將返回類型置于函數(shù)名之前. 例如:

int foo(int x);

C++11 引入了這一新的形式. 現(xiàn)在可以在函數(shù)名前使用auto關(guān)鍵字, 在參數(shù)列表之后后置返回類型. 例如:

auto foo(int x) -> int;

后置返回類型為函數(shù)作用域. 對于像int這樣簡單的類型, 兩種寫法沒有區(qū)別. 但對于復(fù)雜的情況, 例如類域中的類型聲明或者以函數(shù)參數(shù)的形式書寫的類型, 寫法的不同會造成區(qū)別.

優(yōu)點(diǎn)

后置返回類型是顯式地指定Lambda 表達(dá)式的返回值的唯一方式. 某些情況下, 編譯器可以自動推導(dǎo)出 Lambda 表達(dá)式的返回類型, 但并不是在所有的情況下都能實(shí)現(xiàn). 即使編譯器能夠自動推導(dǎo), 顯式地指定返回類型也能讓讀者更明了.

有時在已經(jīng)出現(xiàn)了的函數(shù)參數(shù)列表之后指定返回類型, 能夠讓書寫更簡單, 也更易讀, 尤其是在返回類型依賴于模板參數(shù)時. 例如:

template auto add(T t, U u) -> decltype(t + u);

對比下面的例子:

template decltype(declval() + declval()) add(T t, U u);

缺點(diǎn)

后置返回類型相對來說是非常新的語法, 而且在 C 和 Java 中都沒有相似的寫法, 因此可能對讀者來說比較陌生.

在已有的代碼中有大量的函數(shù)聲明, 你不可能把它們都用新的語法重寫一遍. 因此實(shí)際的做法只能是使用舊的語法或者新舊混用. 在這種情況下, 只使用一種版本是相對來說更規(guī)整的形式.

結(jié)論

在大部分情況下, 應(yīng)當(dāng)繼續(xù)使用以往的函數(shù)聲明寫法, 即將返回類型置于函數(shù)名前. 只有在必需的時候 (如 Lambda 表達(dá)式) 或者使用后置語法能夠簡化書寫并且提高易讀性的時候才使用新的返回類型后置語法. 但是后一種情況一般來說是很少見的, 大部分時候都出現(xiàn)在相當(dāng)復(fù)雜的模板代碼中, 而多數(shù)情況下不鼓勵寫這樣復(fù)雜的模板代碼.

5. 來自 Google 的奇技

Google 用了很多自己實(shí)現(xiàn)的技巧 / 工具使 C++ 代碼更加健壯, 我們使用 C++ 的方式可能和你在其它地方見到的有所不同.

5.1. 所有權(quán)與智能指針

> 總述

動態(tài)分配出的對象最好有單一且固定的所有主, 并通過智能指針傳遞所有權(quán).

> 定義

所有權(quán)是一種登記／管理動態(tài)內(nèi)存和其它資源的技術(shù). 動態(tài)分配對象的所有主是一個對象或函數(shù), 后者負(fù)責(zé)確保當(dāng)前者無用時就自動銷毀前者. 所有權(quán)有時可以共享, 此時就由最后一個所有主來負(fù)責(zé)銷毀它. 甚至也可以不用共享, 在代碼中直接把所有權(quán)傳遞給其它對象.

智能指針是一個通過重載*和->運(yùn)算符以表現(xiàn)得如指針一樣的類. 智能指針類型被用來自動化所有權(quán)的登記工作, 來確保執(zhí)行銷毀義務(wù)到位.std::unique_ptr是 C++11 新推出的一種智能指針類型, 用來表示動態(tài)分配出的對象的獨(dú)一無二的所有權(quán); 當(dāng)std::unique_ptr離開作用域時, 對象就會被銷毀.std::unique_ptr不能被復(fù)制, 但可以把它移動（move）給新所有主.std::shared_ptr同樣表示動態(tài)分配對象的所有權(quán), 但可以被共享, 也可以被復(fù)制; 對象的所有權(quán)由所有復(fù)制者共同擁有, 最后一個復(fù)制者被銷毀時, 對象也會隨著被銷毀.

> 優(yōu)點(diǎn)

如果沒有清晰、邏輯條理的所有權(quán)安排, 不可能管理好動態(tài)分配的內(nèi)存.

傳遞對象的所有權(quán), 開銷比復(fù)制來得小, 如果可以復(fù)制的話.

傳遞所有權(quán)也比”借用”指針或引用來得簡單, 畢竟它大大省去了兩個用戶一起協(xié)調(diào)對象生命周期的工作.

如果所有權(quán)邏輯條理, 有文檔且不紊亂的話, 可讀性會有很大提升.

可以不用手動完成所有權(quán)的登記工作, 大大簡化了代碼, 也免去了一大波錯誤之惱.

對于 const 對象來說, 智能指針簡單易用, 也比深度復(fù)制高效.

> 缺點(diǎn)

不得不用指針（不管是智能的還是原生的）來表示和傳遞所有權(quán). 指針語義可要比值語義復(fù)雜得許多了, 特別是在 API 里：這時不光要操心所有權(quán), 還要顧及別名, 生命周期, 可變性以及其它大大小小的問題.

其實(shí)值語義的開銷經(jīng)常被高估, 所以所有權(quán)傳遞帶來的性能提升不一定能彌補(bǔ)可讀性和復(fù)雜度的損失.

如果 API 依賴所有權(quán)的傳遞, 就會害得客戶端不得不用單一的內(nèi)存管理模型.

如果使用智能指針, 那么資源釋放發(fā)生的位置就會變得不那么明顯.

std::unique_ptr的所有權(quán)傳遞原理是 C++11 的 move 語法, 后者畢竟是剛剛推出的, 容易迷惑程序員.

如果原本的所有權(quán)設(shè)計(jì)已經(jīng)夠完善了, 那么若要引入所有權(quán)共享機(jī)制, 可能不得不重構(gòu)整個系統(tǒng).

所有權(quán)共享機(jī)制的登記工作在運(yùn)行時進(jìn)行, 開銷可能相當(dāng)大.

某些極端情況下 (例如循環(huán)引用), 所有權(quán)被共享的對象永遠(yuǎn)不會被銷毀.

智能指針并不能夠完全代替原生指針.

> 結(jié)論

如果必須使用動態(tài)分配, 那么更傾向于將所有權(quán)保持在分配者手中. 如果其他地方要使用這個對象, 最好傳遞它的拷貝, 或者傳遞一個不用改變所有權(quán)的指針或引用. 傾向于使用std::unique_ptr來明確所有權(quán)傳遞, 例如：

std::unique_ptr FooFactory();void FooConsumer(std::unique_ptr ptr);

如果沒有很好的理由, 則不要使用共享所有權(quán). 這里的理由可以是為了避免開銷昂貴的拷貝操作, 但是只有當(dāng)性能提升非常明顯, 并且操作的對象是不可變的（比如說std::shared_ptr）時候, 才能這么做. 如果確實(shí)要使用共享所有權(quán), 建議于使用std::shared_ptr.

不要使用std::auto_ptr, 使用std::unique_ptr代替它.

5.2. Cpplint

> 總述

使用cpplint.py檢查風(fēng)格錯誤.

> 說明

cpplint.py是一個用來分析源文件, 能檢查出多種風(fēng)格錯誤的工具. 它不并完美, 甚至還會漏報(bào)和誤報(bào), 但它仍然是一個非常有用的工具. 在行尾加//NOLINT, 或在上一行加//NOLINTNEXTLINE, 可以忽略報(bào)錯.

某些項(xiàng)目會指導(dǎo)你如何使用他們的項(xiàng)目工具運(yùn)行cpplint.py. 如果你參與的項(xiàng)目沒有提供, 你可以單獨(dú)下載cpplint.py.

譯者（acgtyrant）筆記

把智能指針當(dāng)成對象來看待的話, 就很好領(lǐng)會它與所指對象之間的關(guān)系了.

原來 Rust 的 Ownership 思想是受到了 C++ 智能指針的很大啟發(fā)啊.

scoped_ptr和auto_ptr已過時. 現(xiàn)在是shared_ptr和uniqued_ptr的天下了.

按本文來說, 似乎除了智能指針, 還有其它所有權(quán)機(jī)制, 值得留意.

Arch Linux 用戶注意了, AUR 有對 cpplint 打包.