軟件開發實踐:如何編寫整潔的代碼

最近在工做中, 常常會維護一些已經存在的代碼,常常Review別人的代碼,也常常請別人Review代碼.

感受Review代碼真是一個很累人的工做.感謝那些爲咱們Review代碼的同事.

不少時候,感受Review的效果並很差,難以深刻下去.

如何Review好代碼,當前尚未太好的思路,結對編程是一個方法,可是本身沒有實踐過,僅僅在思考的層面上,因此也難以有發言權.

可是,如何方便別人Review,如何提升本身的代碼質量,卻是總結了一些內容,本我大打算主要站在C/C++開發人員的角度寫一下本身的總結.

有本書叫<代碼整潔之道>, 主要就是講述怎麼寫整潔代碼的.一直以來,感受本身寫代碼還算是整潔,可是看了這本書後,仍是頗有收穫.

別人的東西畢竟是別人的,本身理解的不必定到位,在這裏我把本身理解的整潔的代碼整理一下.想到哪兒寫到哪兒,條目未必都在一個層次上,有點亂,也不全,之後會持續整理:

1控制可見範圍

我以爲代碼中,控制可見範圍最重要.

l  能放在源文件中的不要放在頭文件中

由於頭文件的可見範圍比源文件大,可能被別處使用.

能被別處使用的代碼，之後就不敢輕易修改, 會使代碼愈來愈僵化.

看代碼時, 增長閱讀代碼負擔, 會關心是否被其餘地方使用.追溯代碼時，擴大追溯範圍.

頭文件中信息太多, 會使頭文件更復雜.

l  能用static的，必定要用static

在源文件中,static的函數或者變量,咱們能夠隨便改,由於這些變量或函數的範圍只在不會超出文件.可是非static的,要改動時就要當心了. 閱讀代碼時,也會考慮它爲何不是static的,會不會被其餘地方調用.

l  在類中,能用private的不用protected,能用protected的,不用public.

2 頭文件

l  抽象層次不一樣的代碼不要放在一塊兒，特別是頭文件

不這樣作，在使用 寫makefile時， 可能須要include一大堆不相干的文件夾.甚至可能出現類型衝突.

l  常量，枚舉若是可能，最好和結構體分離，特別是與具體業務聯繫密切的結構體， 最好對結構體也劃分好層級

若是用於ioctl之類的頭文件，最好不要出現函數

l  能不include的頭文件不要引用

l  若是是庫， 對外接口能寫成C接口的，儘可能寫成C接口，而不是C++接口.

3 變量

l  不要對外暴露變量，而是接口

變量未通過抽象，描述性差.

變量暴露了細節. 例若有些類型能夠是模塊私有的，若是暴露變量，則該類型可能須要設置爲外部可見的

l  變量必定要初始化

l  儘可能以只讀常量代替宏

4 函數

l  不要有長函數

長函數有不少的不方便:

1難以閱讀

2 不知道邏輯段長短

有些邏輯段特別長

3 if/else一大堆

4 有些變量聲明的地方距離使用的位置比較遠

特別是C代碼

5 縮進太多

邏輯不明顯

代碼列數增加

6 沒有對代碼進行抽象

全部代碼都是細節

描述性差

7 未分層，分函數

函數名具備描述性

8 拆分大函數是重構，模式靈感的重要來源之一

從新抽象的過程

9 長的函數難以寫單元測試

可能違反單一職責原則,一個函數幹多件事

沒有好的分層,沒法方便的mock

沒法分多個層測試

5註釋

l  儘可能不添加多餘的註釋

讓代碼具備自描述性.這要求咱們在代碼的自描述性上下功夫.例如名稱,格式等.

l  有些註釋要加

例如假設,限制條件,依賴或調用順序,不說別人不知道的知識.

調用順序儘可能讓代碼作到不順序調用沒法使用(例如<代碼整潔之道>中的’ 把邏輯依賴改成物理依賴’),可是有時候也不得不使用註釋來解決,可是這不是好的方法.

6 不要將C++當C使用

l  局部變量不須要再最前面聲明

使用時才聲明

l  有種參數叫引用參數&

不少地方可使用引用參數或const type&代替指針參數

l  不須要類時，不要刻意用類

畢竟增長複雜度

l  能用泛型時儘可能用泛型

泛型能解決不少不用泛型沒法進行的抽象.

使用泛型不會有太大的代價.

編譯速度可能會變慢

l  C++新標準中， function對象和Lamda表達式是很好用的東西，儘可能用好

有種範式是函數式編程,使用好function對象和Lamda表達式是一種函數式編程的實驗.

l  儘可能不使用繼承實現擴展

l  對外的接口最好寫成C的

l  數據和操做最好在一個類中，而不是分開

這一點我是有些疑問的.

l  若是一個類中的全部成員都是static的，建議使用namespace代替類

同一命名空間， 能夠放在多個文件中

使用時，可使用using namespace 節省輸入

l  使用#program once代替頭文件中的宏判斷和定義來保證頭文件的惟一性

l  類名有描述性,不須要在成員變量中再重複類名相關的描述文字

l  使用bool類型代替BOOL

BOOL是用戶自定義類型,可能存在TRUE爲0的狀況,bool不會存在這種狀況.

若是使用BOOL,請不要將TRUE當作true,FALSE當作FALSE.不要從新定義TRUE和FALSE