C++代碼需要遵循的10個(gè)最佳實(shí)踐

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

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

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

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

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

現(xiàn)代C++庫廣泛使用命名空間來模塊化代碼庫，它們利用“Namespace-by-feature”方法，按功能劃分命名空間來反映功能集，將單個(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)。

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

4. 類越小越好

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

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

BigClass中的邏輯必須被分成更小的類。這些較小的類最終可能成為嵌套在原始God Class中的私有類，God Class的實(shí)例對(duì)象由較小嵌套類的實(shí)例組成。

較小的類劃分應(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)類。純靜態(tài)方法是一種只根據(jù)輸入參數(shù)計(jì)算結(jié)果的函數(shù)，它不讀取或分配任何靜態(tài)或?qū)嵗侄?。純靜態(tài)方法的主要優(yōu)點(diǎn)是易于測(cè)試。

首先嘗試維護(hù)BigClass的接口，并委托調(diào)用新提取的類。最后，BigClass應(yīng)該是一個(gè)沒有自己邏輯的純接口，可以為了方便將其保留，也可以將其扔掉，并開始只使用新類。

單元測(cè)試可以提供幫助: 在提取方法之前為每個(gè)方法編寫測(cè)試，以確保不會(huì)破壞功能。

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

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

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

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

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

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

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

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

單一責(zé)任原則規(guī)定一個(gè)類不應(yīng)該有多于一個(gè)更改的理由，這樣的類被稱為內(nèi)聚類。較高的LCOM值通?？梢砸馕吨惖膬?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是類中方法的數(shù)量(包括靜態(tài)方法和實(shí)例方法，它還包括構(gòu)造函數(shù)、屬性getter/setter、事件添加/刪除方法)。

F是類中實(shí)例字段的數(shù)量。

MF是類訪問特定實(shí)例字段的方法數(shù)量。

Sum(MF)是該類所有實(shí)例字段的MF之和。

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

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

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

鸚鵡學(xué)舌的代碼注釋沒有為讀者提供任何額外的東西。代碼庫中充斥著嘈雜的注釋和不正確的注釋，促使程序員忽略所有的注釋，或者采取積極的措施隱藏它們。

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

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

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

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

10. 不變性有助于多線程編程

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

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

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

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

如果沒有公共字段，沒有可以更改其內(nèi)部數(shù)據(jù)的方法，并且派生類方法無法更改其內(nèi)部數(shù)據(jù)，那么引用對(duì)象類就是不可變的。因?yàn)橹挡豢勺?，所以在所有情況下都可以引用相同的對(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]的代碼查詢語言，可以像數(shù)據(jù)庫一樣查詢代碼庫。開發(fā)人員、設(shè)計(jì)人員和架構(gòu)師可以自定義查詢，以便輕松找到容易出現(xiàn)bug的情況。

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

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

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

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

References:

[1] 10 Best practices to design and implement a C++ class: https://issamvb.medium.com/10-best-practices-to-design-and-implement-a-c-class-4326611827e1#:~:text=10%20Best%20practices%20to%20design%20and%20implement%20a,class%20as%20you%20can.%20...%20More%20items...%20

[2] Explicitly defaulted and deleted special member functions: http://en.wikipedia.org/wiki/C%2B%2B11#Explicitly_defaulted_and_deleted_special_member_functions

[3] CppDepend: http://www.cppdepend.com/

[4] CQLinq: https://www.cppdepend.com/cqlinq

編輯：黃飛

?