整潔的代碼在團隊中無疑是很受歡迎的，可以高效的被其它成員理解和維護，本文參考《C++代碼整潔之道》和《Google C++編碼規(guī)范》，結合自己的一些想法整理如下：

C++本身作為面向?qū)ο笳Z言，首先介紹下面向?qū)ο笠话闵婕暗降拈_發(fā)原則。

面向?qū)ο箝_發(fā)原則

1. 依賴倒置原則：針對接口編程，依賴于抽象而不依賴于具體，抽象(穩(wěn)定)不應依賴于實現(xiàn)細節(jié)(變化)，實現(xiàn)細節(jié)應該依賴于抽象，因為穩(wěn)定態(tài)如果依賴于變化態(tài)則會變成不穩(wěn)定態(tài)。

2. 開放封閉原則：對擴展開放，對修改關閉，業(yè)務需求是不斷變化的，當程序需要擴展的時候，不要去修改原來的代碼，而要靈活使用抽象和繼承，增加程序的擴展性，使易于維護和升級，類、模塊、函數(shù)等都是可以擴展的，但是不可修改。

3. 單一職責原則：一個類只做一件事，一個類應該僅有一個引起它變化的原因，并且變化的方向隱含著類的責任。

4. 里氏替換原則：子類必須能夠替換父類，任何引用基類的地方必須能透明的使用其子類的對象，開放關閉原則的具體實現(xiàn)手段之一。

5. 接口隔離原則：接口最小化且完備，盡量少public來減少對外交互，只把外部需要的方法暴露出來。

6. 最少知道原則：一個實體應該盡可能少的與其他實體發(fā)生相互作用。

7. 將變化的點進行封裝，做好分界，保持一側變化，一側穩(wěn)定，調(diào)用側永遠穩(wěn)定，被調(diào)用側內(nèi)部可以變化。

8. 優(yōu)先使用組合而非繼承，繼承為白箱操作，而組合為黑箱，繼承某種程度上破壞了封裝性，而且父類與子類之間耦合度比較高。

9. 針對接口編程，而非針對實現(xiàn)編程，強調(diào)接口標準化。

C++開發(fā)原則

通過上述面向?qū)ο箝_發(fā)原則的理解可以細化到具體C++開發(fā)原則。 

• 保持簡單和直接原則(KISS, Keep it simple and stupid)：保持代碼盡可能簡單，如果需求需要的話，才在代碼中引入靈活的可變點，只添加那些可使整體變得更簡單的局部復雜的東西。

• 不需要原則(YAGNI, You're not gonna need it)：總是在你真正需要的時候再實現(xiàn)他們，而不是在你只是預見到你將來會需要他們而去實現(xiàn)，在真正需要的時候再寫代碼，那時再重構也來得及。

• 避免復制原則(DRY, Do not repeat yourself)：不要復制，不要重復，這是相當危險的操作，你修改一處代碼的時候總能記得去修改另外一處或另外多處你曾經(jīng)復制的代碼嗎？

• 信息隱藏原則：一段代碼調(diào)用了另外一段代碼，調(diào)用者不應該知道被調(diào)用者代碼的實現(xiàn)，否則調(diào)用者就有可能修改被調(diào)用者的實現(xiàn)來實現(xiàn)某些功能，而這有可能引發(fā)其它調(diào)用者的bug。

• 高內(nèi)聚低耦合原則：類似單一職責原則，明確每個模塊的具體責任，盡量少的依賴于其它模塊。

• 最少驚訝原則：函數(shù)功能要與函數(shù)名字功能一致，難道你要在一個getter()函數(shù)去更改成員變量的值嗎？

• 更干凈原則(自命名)：離開露營地的時候，應讓露營地比你來之前還要干凈，當發(fā)現(xiàn)代碼中有需要改進或者風格不好的地方，應該立刻改掉，不要care這段代碼的原作者是誰，也不要care這是誰的模塊，代碼所有權是集體的，每個團隊成員在任何時候都應該可以對任何代碼進行更改和擴展。

關于面向?qū)ο笤O計原則可以參考一文讓你搞懂設計模式

注重單元測試

重要性就不多說了，防患于未然，構建大型系統(tǒng)尤其需要進行單元測試，保證代碼質(zhì)量，可以防患于未然。一般都講究測試驅(qū)動開發(fā)，開發(fā)一個功能首先要想好怎么測試，先把測試代碼寫好，再去開發(fā)對應的需求。通過單元測試也有利于開發(fā)者更好的進行接口的設計，主要說下良好的單元測試的原則。

單元測試的原則

• 保證單元測試的代碼的質(zhì)量，單元測試的代碼也是代碼，不應該和產(chǎn)品代碼區(qū)別對待，而且單元測試的代碼再寫出bug更影響測試效率。

• 單元測試的命名， 每個測試單元需要根據(jù)具體測試內(nèi)容進行相應的命名，方便定位分析問題，好的命名如果出現(xiàn)問題時通過測試單元的名字基本就可以定位問題。

• 保證單元測試的獨立性，每個測試單元都是獨立的，不依賴于其它測試單元，不要構建測試單元的上下文，上面的測試單元出問題影響到下面的單元測試的設計是很不友好的。

• 盡量保證一個測試單元使用一個斷言，保證測試單元內(nèi)部的一個相對獨立性，上面的斷言阻礙了下面的斷言測試也是不好的設計。

• 保證單元測試環(huán)境的獨立，保證每個測試單元都有獨立的環(huán)境，不依賴于其它環(huán)境，每個測試單元都要是個獨立的可運行的實例，每個單元測試結束后記得清理環(huán)境。

• 沒必要對第三方庫和外部系統(tǒng)做單元測試，只對自己寫的代碼進行測試。

• 單元測試盡量不要涉及數(shù)據(jù)庫，數(shù)據(jù)庫的狀態(tài)是全局的，測試不能保證獨立性，而且數(shù)據(jù)庫的訪問也是緩慢的，影響單元測試的速度，如果真的需要可以模擬數(shù)據(jù)庫在內(nèi)容中進行測試，其實通常是在系統(tǒng)集成和系統(tǒng)測試級別時去測試數(shù)據(jù)庫。

• 不要混淆測試代碼和產(chǎn)品代碼，產(chǎn)品代碼中不應依賴測試代碼。

• 測試必須要快速執(zhí)行，確保秒級別，大型系統(tǒng)的單元測試也就幾分鐘而已，單元測試不要訪問數(shù)據(jù)庫、磁盤、網(wǎng)絡等外設。

• 找一些測試替身，例如有些數(shù)據(jù)需要通過網(wǎng)絡獲取，那可以利用依賴注入做一個網(wǎng)絡替身的類模擬這些數(shù)據(jù)的產(chǎn)生，可以研究研究Google mock。

良好的命名

無論是什么語言，函數(shù)和變量的良好命名都是很有必要的，通過函數(shù)的名字我們就可以知道這個函數(shù)里代碼的作用，而不是通過寫注釋，個人一直傾向于用代碼自解釋。

文件命名

文件名字要全部小寫，中間用_相連，后綴名為.cc和.h

類型命名

類型名稱的每個單詞首字母均大寫, 不包含下劃線: MyExcitingClass, MyExcitingEnum.

變量命名

不要將變量的類型在名字中體現(xiàn)，這樣以后變量類型改變的話還需要去改動變量名，充分利用IDE的功能，變量 (包括函數(shù)參數(shù)) 和數(shù)據(jù)成員名一律小寫, 單詞之間用下劃線連接. 類的成員變量以下劃線結尾, 但結構體的就不用, 如: a_local_variable, a_struct_data_member, a_class_data_member_.

class TableInfo {...private:string table_name_; // 好 - 后加下劃線.string tablename_; // 好.static Pool<TableInfo>* pool_; // 好.int i_table; // 不好，不要將變量的類型在名字中體現(xiàn)};

常量命名

聲明為 constexpr 或 const 的變量, 或在程序運行期間其值始終保持不變的, 命名時以 “k” 開頭, 大小寫混合

const int kDaysInAWeek = 7;

函數(shù)命名

常規(guī)函數(shù)使用大小寫混合, 取值和設值函數(shù)則要求與變量名匹配: MyExcitingFunction(), MyExcitingMethod(), my_exciting_member_variable(), set_my_exciting_member_variable().

枚舉命名

和常量一致

enum UrlTableErrors { kOK = 0, kErrorOutOfMemory, kErrorMalformedInput,};

Tip:

除非像swap函數(shù)里tmp那種一目了然，否則不要搞無意義的命名，函數(shù)名變量名字寧可特別長也要寫清楚究竟是什么意思，不要用縮寫，一個變量盡量在臨近使用前才定義，可讀性強也可更好利用cpu cache。

編輯器

團隊可以統(tǒng)一使用相同的編輯器，個人目前使用的是VS Code編輯器，同時每個項目使用統(tǒng)一的.clang_format文件，統(tǒng)一規(guī)范代碼格式，所有的換行符都要用LF格式，不要用CRLF格式，在右下角可以設置。

個人的.clang-format文件如下，是在google風格的基礎上做了些修改：

BasedOnStyle: GoogleIndentWidth: 4ColumnLimit: 120SortIncludes: trueMaxEmptyLinesToKeep: 2

C++編碼規(guī)范要點小總結

• 每個頭文件都要使用#define避免被重復引用

命名格式 <PROJECT>_<PATH>_<FILE>_H_
#ifndef FOO_BAR_BAZ_H_#define FOO_BAR_BAZ_H_...#endif // FOO_BAR_BAZ_H_

或使用#pragma once，而#define方式更通用

• 鼓勵在 .cc 文件內(nèi)使用匿名命名空間或 static 聲明. 使用具名的命名空間時, 其名稱可基于項目名或相對路徑. 禁止使用 using 指示， 禁止使用內(nèi)聯(lián)命名空間（inline namespace）  

• 一行盡量不要超過120個字符，一個函數(shù)盡量不要超過40行，同時一個文件盡量控制在500行內(nèi).  

• 所有的引用形參如不做改動一律加const，在任何可能的情況下都要使用 const或constexpr  

• new內(nèi)存的地方盡量使用智能指針，c++11 就盡量用std::unique_ptr替代std::auto_ptr  

• 合理使用移動語義，減少內(nèi)存拷貝，參考左值引用、右值引用、移動語義、完美轉(zhuǎn)發(fā)，你知道的不知道的都在這里

• 禁止使用 RTTI，盡量在編譯期間就確定參數(shù)類型，不要搞運行時識別typeid這種代碼  

• 使用 C++ 的類型轉(zhuǎn)換, 如 static_cast<>(). 不要使用 int y = (int)x 或 int y = int(x) 等轉(zhuǎn)換方式    

• 明確使用前置++還是后置++的具體含義，如不考慮返回值，盡量使用效率高的前置++ (++i)  

• 不要使用uint類型，如果需要使用大整型可以考慮int64，否則類型的隱式類型轉(zhuǎn)換會帶來很多麻煩  

• 如無特殊必要不要使用宏，可以考慮使用const或constexpr替代宏，宏的全局作用域很麻煩，如果非要用在馬上要使用時才進行 #define, 使用后要立即 #undef    

• google文檔說一定不要用宏來控制條件編譯(但是我自己還沒有查到不用宏如何控制條件編譯，或許就不要搞條件編譯)  

• 盡可能用 sizeof(varname) 代替 sizeof(type).使用 sizeof(varname) 是因為當代碼中變量類型改變時會自動更新. 您或許會用 sizeof(type) 處理不涉及任何變量的代碼，比如處理來自外部或內(nèi)部的數(shù)據(jù)格式，這時用變量就不合適了  

• 類型名如果過長的話可以考慮使用auto關鍵字  

• 注釋統(tǒng)一使用 // ，不要通過注釋禁用代碼，擅用git，不要為易懂的代碼寫注釋

• 寫完代碼后記得format，VS Code(windows快捷鍵) shift + alt + F ，每個項目最好都有統(tǒng)一的.clang_format文件  

• 使用C++的string和stream替代C語言風格的char*，使用std::ostream和std::cout替代printf()、sprintf()等

• 盡量使用STL標準庫的容器而不是C語言風格的數(shù)組，數(shù)組的越界訪問之類當時是不會報錯的，反而可能弄臟堆棧信息，導致奇奇怪怪難以排查的bug

• 可以更多的使用模板元編程，盡量多的使用constexpr等編譯器計算，編譯器是我們的好搭檔，個人認為模板元編程以后會是C++的主流技術

• 可以考慮更多的使用異常處理方式，而不是C語言風格的errno錯誤碼等，這里可以參考你的c++團隊還在禁用異常處理嗎？

附：本文不是技術文章，介紹較為主觀，可能和很多人想法有所沖突，各位可以結合自己的經(jīng)歷經(jīng)驗酌情參考。

參考資料

《C++代碼整潔之道》

https://zh-google-styleguide.readthedocs.io/en/latest/google-cpp-styleguide/contents/

c++11新特性，所有知識點都在這了！

你的c++團隊還在禁用異常處理嗎？

內(nèi)存對齊之格式修訂版

c++11新特性之智能指針