分析一套源代碼的代碼規範和風格並討論如何改進優化代碼

　　個人工程實踐主要任務爲實現一個搜索引擎，所以我在github上找到了一個與我主題契合的C++搜索引擎開源項目-TypeSense作分析。

　　1. 源代碼目錄結構

　   　　該工程總體目錄結構比較清晰，從上到下內容依次爲：

　　　　.circleci：持續集成工具的配置文件

　　　　assets：主要爲軟件Logo

　　　　cmake: 管理工程構建，生成makefile

　　　　docket：一系列dockerfile，用於生成docket鏡像

　　　　include：C++頭文件

　　　　src：C++源文件

　　　　test：單元測試　　

　　　　此外根目錄下還包含了一些構建工程用的Shell腳本、Cmake規則、README和許可證文件。能夠看出整個工程目錄結構屬於比較常規的C++項目目錄結構。

　　

　　2. 文件名/類名/函數名/變量名等命名 

　　源代碼文件名命名總體比較清晰，絕大多數文件看到命名能大概猜到是用於作什麼的。命名大多使用了完整的有意義的英文單詞，即便使用了英文單詞縮寫也屬於計算機領域內經常使用縮寫，如"cmd"->"command"，"exec"->"execute"，令讀者沒有太多心智負擔。

　　源碼中類名都使用了大寫字母開頭，函數名使用小寫下劃線命名，變量名使用小寫下劃線命名，宏名全大寫，均爲描述性名稱，符合代碼規範和風格通常要求。總體看起來基本清楚，名字容易讓人理解。　　

　　可是類中private成員變量沒有加下劃線（不管是加在開頭仍是末尾），這樣作我認爲沒有加下劃線看起來清晰。

　　　　此外存在函數參數過多的問題，多達十幾個參數，一長串參數調用起來也十分不便。

 

　　　　建議把相關的參數打包成一個類，特別是一些配置參數能夠打包成param類，比傳一長串參數進去要好。OpenCV中就有相似作法：

　　　　

　　3. 接口定義規範　　

　　如圖爲該項目中的某個接口：

 

　　我建議將接口類使用大寫字母Ｉ開頭來命名，或者以"Interface"結尾，這樣能很容易地看出來是個接口類，符合清晰的原則。

 

　　4. 單元測試組織形式　　

　　該項目使用的測試框架爲Google的gest，這也是我寫C++項目最經常使用的測試框架。能夠看到做者把全部單元模塊的測試代碼以及測試用例文件都堆雜在一塊兒，很難讓人一眼看清楚哪些文件測試的是哪一個單元。

　　　　改進建議：根據我閱讀過的開源項目作法以及我本身踐行的作法，通常是在整個test單元測試文件夾下爲每一個單元測試單獨創建新的文件夾，以此工程爲例：能夠創建array_test文件夾裏面放入array_test.cpp以及其餘依賴（或依賴的引用），創建store_test文件夾裏面放入store_test.cpp及其依賴...  顯然這樣看起來會很清楚，哪些文件是用於測試哪一個模塊的一目瞭然。

　　5.　C++項目代碼規範和風格要求

　　關於代碼風格和規範其實有不少種，青菜蘿蔔各有所愛，一個團隊內保持一致便可。我比較喜歡的C++代碼規範和風格是Google內部使用的，如圖：

　　我在實踐中也基本遵循這套規範，它使我代碼看起來更加清晰，而且減小歧義。