C++代碼提供了足夠的靈活性，因此對(duì)于大部分工程師來(lái)說(shuō)都很難把握。本文介紹了寫(xiě)好C++代碼需要遵循的10個(gè)最佳實(shí)踐，并在最后提供了一個(gè)工具可以幫助我們分析C++代碼的健壯度。

1. 盡可能?chē)L試使用新的C++標(biāo)準(zhǔn)

到2022年，C++已經(jīng)走過(guò)了40多個(gè)年頭。新的C++標(biāo)準(zhǔn)實(shí)際上簡(jiǎn)化了許多令人沮喪的細(xì)節(jié)，提供了新的現(xiàn)代方法來(lái)改進(jìn)C++代碼，但讓開(kāi)發(fā)人員認(rèn)識(shí)到這一點(diǎn)并不容易。

以?xún)?nèi)存管理為例，這可能是C++中受到最多批評(píng)的機(jī)制。多年來(lái)，對(duì)象分配都是由new關(guān)鍵字完成的，開(kāi)發(fā)人員一定得記住在代碼的某個(gè)地方調(diào)用delete。“現(xiàn)代C++”解決了這個(gè)問(wèn)題，并促進(jìn)了共享指針的使用。

2. 使用命名空間模塊化代碼

現(xiàn)代C++庫(kù)廣泛使用命名空間來(lái)模塊化代碼庫(kù)，它們利用“Namespace-by-feature”方法，按功能劃分命名空間來(lái)反映功能集，將單個(gè)特性(且僅與該特性)相關(guān)的所有內(nèi)容放到單個(gè)命名空間中。從而使得命名空間具有高內(nèi)聚性和高模塊化，并且耦合最小，緊耦合的項(xiàng)目被放在了一起。

Boost是按特性分組的最佳示例，其包含數(shù)千個(gè)命名空間，每個(gè)命名空間用于對(duì)特定的特性進(jìn)行分組。

3. 抽象

數(shù)據(jù)抽象是C++中面向?qū)ο?a target="_blank">編程最基本和最重要的特性之一。抽象意味著只顯示基本信息而隱藏細(xì)節(jié)，數(shù)據(jù)抽象指的是僅向外部世界提供關(guān)于數(shù)據(jù)的基本信息，隱藏背景細(xì)節(jié)或?qū)崿F(xiàn)。

盡管許多書(shū)籍、網(wǎng)絡(luò)資源、會(huì)議演講者和專(zhuān)家都推薦這種最佳實(shí)踐，但在很多項(xiàng)目中，這條規(guī)則仍然被忽略了，許多類(lèi)的細(xì)節(jié)并沒(méi)有被隱藏。

4. 類(lèi)越小越好

具有多行代碼的類(lèi)型應(yīng)該被劃分為一組較小的類(lèi)型。

需要很大的耐心重構(gòu)一個(gè)大的類(lèi)，甚至可能需要從頭重新創(chuàng)建所有東西。以下是一些重構(gòu)建議:

• BigClass中的邏輯必須被分成更小的類(lèi)。這些較小的類(lèi)最終可能成為嵌套在原始God Class中的私有類(lèi)，God Class的實(shí)例對(duì)象由較小嵌套類(lèi)的實(shí)例組成。
• 較小的類(lèi)劃分應(yīng)該由God Class負(fù)責(zé)的多個(gè)職責(zé)驅(qū)動(dòng)。要確定這些職責(zé)，通常需要查找與字段的子集強(qiáng)耦合的方法的子集。
• 如果BigClass包含的邏輯比狀態(tài)多，一個(gè)好的選擇是定義一個(gè)或幾個(gè)不包含靜態(tài)字段而只包含純靜態(tài)方法的靜態(tài)類(lèi)。純靜態(tài)方法是一種只根據(jù)輸入參數(shù)計(jì)算結(jié)果的函數(shù)，它不讀取或分配任何靜態(tài)或?qū)嵗侄巍＜冹o態(tài)方法的主要優(yōu)點(diǎn)是易于測(cè)試。
• 首先嘗試維護(hù)BigClass的接口，并委托調(diào)用新提取的類(lèi)。最后，BigClass應(yīng)該是一個(gè)沒(méi)有自己邏輯的純接口，可以為了方便將其保留，也可以將其扔掉，并開(kāi)始只使用新類(lèi)。
• 單元測(cè)試可以提供幫助: 在提取方法之前為每個(gè)方法編寫(xiě)測(cè)試，以確保不會(huì)破壞功能。

5. 每個(gè)類(lèi)盡量提供最少的方法

包含20個(gè)以上方法的類(lèi)可能很難理解和維護(hù)。

一個(gè)類(lèi)有許多方法可能是實(shí)現(xiàn)了太多責(zé)任的癥狀。

也許所面對(duì)的類(lèi)控制了系統(tǒng)中太多的其他類(lèi)，并且已經(jīng)超出了應(yīng)有的邏輯，成為了一個(gè)無(wú)所不能的類(lèi)。

6. 加強(qiáng)低耦合

低耦合是理想狀態(tài)，可以在應(yīng)用中進(jìn)行較少的更改實(shí)現(xiàn)程序的某個(gè)變更。從長(zhǎng)遠(yuǎn)來(lái)看，可以減少修改、添加新特性的大量時(shí)間、精力和成本。

低耦合可以通過(guò)使用抽象類(lèi)或泛型類(lèi)和方法來(lái)實(shí)現(xiàn)。

7. 加強(qiáng)高內(nèi)聚

單一責(zé)任原則規(guī)定一個(gè)類(lèi)不應(yīng)該有多于一個(gè)更改的理由，這樣的類(lèi)被稱(chēng)為內(nèi)聚類(lèi)。較高的LCOM值通常可以意味著類(lèi)的內(nèi)聚性較差。有幾個(gè)LCOM指標(biāo)，取值范圍為[0-1]。LCOM HS (HS代表Henderson-Sellers)取值范圍為[0-2]。LCOM HS值大于1時(shí)需要產(chǎn)生警惕。下面是計(jì)算LCOM指標(biāo):

LCOM = 1 — (sum(MF)/M*F)
LCOM HS = (M — sum(MF)/F)(M-1)

其中……

• M是類(lèi)中方法的數(shù)量(包括靜態(tài)方法和實(shí)例方法，它還包括構(gòu)造函數(shù)、屬性getter/setter、事件添加/刪除方法)。
• F是類(lèi)中實(shí)例字段的數(shù)量。
• MF是類(lèi)訪(fǎng)問(wèn)特定實(shí)例字段的方法數(shù)量。
• Sum(MF)是該類(lèi)所有實(shí)例字段的MF之和。

這些公式背后的基本思想可以表述如下: 如果一個(gè)類(lèi)的所有方法都使用它的所有實(shí)例字段，那么這個(gè)類(lèi)就是完全內(nèi)聚的，這意味著sum(MF)=M*F，然后LCOM = 0和LCOMHS = 0。

LCOMHS值大于1就需要警惕了。

8. 只注釋代碼不能表達(dá)的內(nèi)容

鸚鵡學(xué)舌的代碼注釋沒(méi)有為讀者提供任何額外的東西。代碼庫(kù)中充斥著嘈雜的注釋和不正確的注釋?zhuān)偈?a target="_blank">程序員忽略所有的注釋?zhuān)蛘卟扇》e極的措施隱藏它們。

9. 盡量不要用重復(fù)的代碼

眾所周知，重復(fù)代碼的存在對(duì)軟件開(kāi)發(fā)和維護(hù)有負(fù)面影響。實(shí)際上，一個(gè)主要缺點(diǎn)是，當(dāng)為了修復(fù)bug或添加新特性而更改重復(fù)代碼的實(shí)例時(shí)，所有對(duì)應(yīng)的代碼必須同時(shí)更改。

產(chǎn)生重復(fù)代碼最常見(jiàn)的原因是復(fù)制/粘貼操作，這種情況下，相似的源代碼出現(xiàn)在兩個(gè)或多個(gè)地方。許多文章、書(shū)籍和網(wǎng)站都警告不要采用這種做法，但有時(shí)實(shí)踐這些建議并不容易，開(kāi)發(fā)人員還是會(huì)選擇簡(jiǎn)單的解決方案: 復(fù)制/粘貼大法。

使用適當(dāng)?shù)墓ぞ呖梢匀菀椎膹膹?fù)制/粘貼操作中檢測(cè)到重復(fù)代碼，但是，在某些情況下，克隆代碼很難被檢測(cè)到。

10. 不變性有助于多線(xiàn)程編程

基本上，如果對(duì)象在創(chuàng)建之后狀態(tài)不變，那么這個(gè)對(duì)象就是不可變(immutable)的。如果一個(gè)類(lèi)的實(shí)例是不可變的，那么該類(lèi)就是不可變的。

不可變對(duì)象極大簡(jiǎn)化了并發(fā)編程，這是支持使用它的重要理由。想想看，為什么編寫(xiě)適當(dāng)?shù)亩嗑€(xiàn)程程序是一項(xiàng)艱巨的任務(wù)？因?yàn)橥骄€(xiàn)程訪(fǎng)問(wèn)資源(對(duì)象或其他操作系統(tǒng)資源)是很困難的。為什么同步這些訪(fǎng)問(wèn)很困難？因?yàn)楹茈y保證多個(gè)線(xiàn)程對(duì)多個(gè)對(duì)象進(jìn)行的多次寫(xiě)訪(fǎng)問(wèn)和讀訪(fǎng)問(wèn)之間不會(huì)出現(xiàn)競(jìng)爭(zhēng)條件。如果不再有寫(xiě)訪(fǎng)問(wèn)會(huì)怎么樣？換句話(huà)說(shuō)，如果被線(xiàn)程訪(fǎng)問(wèn)的對(duì)象的狀態(tài)沒(méi)有改變會(huì)怎么樣？就不再需要同步了！

關(guān)于不可變類(lèi)的另一個(gè)好處是它們永遠(yuǎn)不會(huì)違反里氏替換原則(LSP, Liskov Subtitution Principle)，以下是維基百科對(duì)LSP的定義:

Liskov的行為子類(lèi)型的概念定義了可變對(duì)象可替換性的概念，也就是說(shuō)，如果S是T的子類(lèi)型，那么程序中T類(lèi)型的對(duì)象可以被替換為S類(lèi)型的對(duì)象，而不改變?cè)摮绦虻娜魏纹谕麑傩?例如，正確性)。

如果沒(méi)有公共字段，沒(méi)有可以更改其內(nèi)部數(shù)據(jù)的方法，并且派生類(lèi)方法無(wú)法更改其內(nèi)部數(shù)據(jù)，那么引用對(duì)象類(lèi)就是不可變的。因?yàn)橹挡豢勺儯栽谒星闆r下都可以引用相同的對(duì)象，不需要復(fù)制構(gòu)造函數(shù)或賦值操作符。出于這個(gè)原因，建議將復(fù)制構(gòu)造函數(shù)和賦值操作符設(shè)為私有，或者從boost::noncopyable繼承，或者使用新的C++ 11特性“顯式默認(rèn)和刪除特殊成員函數(shù)”^[2]。

如何加強(qiáng)對(duì)這些最佳實(shí)踐進(jìn)行檢查?

CppDepend^[3]提供了名為CQLinq^[4]的代碼查詢(xún)語(yǔ)言，可以像數(shù)據(jù)庫(kù)一樣查詢(xún)代碼庫(kù)。開(kāi)發(fā)人員、設(shè)計(jì)人員和架構(gòu)師可以自定義查詢(xún)，以便輕松找到容易出現(xiàn)bug的情況。

通過(guò)CQLinq，可以結(jié)合來(lái)自代碼度量、依賴(lài)關(guān)系、API使用和其他模型的數(shù)據(jù)來(lái)定義非常高級(jí)的查詢(xún)，以匹配容易出現(xiàn)bug的情況。

例如，分析clang源代碼后，可以檢測(cè)到大類(lèi):

檢測(cè)到有大量方法的類(lèi):

或者檢測(cè)到內(nèi)聚性較差的類(lèi):

　　審核編輯：湯梓紅

?