寫出整潔的程式碼,是每個程式設計師的追求

本文作者:xybaby 來源:https://www。cnblogs。com/xybaby/p/11335829。html

寫出整潔的程式碼,是每個程式設計師的追求

。《clean code》指出,要想寫出好的程式碼,首先得知道什麼是骯髒程式碼、什麼是整潔程式碼;然後透過大量的刻意練習,才能真正寫出整潔的程式碼。

WTF/min是衡量程式碼質量的唯一標準,Uncle Bob在書中稱糟糕的程式碼為沼澤(wading),這隻突出了我們是糟糕程式碼的受害者。國內有一個更適合的詞彙:屎山,雖然不是很文雅但是更加客觀,程式設計師既是受害者也是加害者。

對於什麼是整潔的程式碼,書中給出了大師們的總結:

Bjarne Stroustrup:優雅且高效;直截了當;減少依賴;只做好一件事

Grady booch:簡單直接

Dave thomas:可讀,可維護,單元測試

Ron Jeffries:不要重複、單一職責,表達力(Expressiveness)

其中,我最喜歡的是表達力(Expressiveness)這個描述,這個詞似乎道出了好程式碼的真諦:用簡單直接的方式描繪出程式碼的功能,不多也不少。

命名的藝術

坦白的說,命名是一件困難的事情,要想出一個恰到好處的命名需要一番功夫,尤其我們的母語還不是程式語言所通用的英語。不過這一切都是值得了,好的命名讓你的程式碼更直觀,更有表達力。

好的命名應該有下面的特徵:

名副其實

好的變數名告訴你:是什麼東西,為什麼存在,該怎麼使用

如果需要透過註釋來解釋變數,那麼就先得不那麼名副其實了。

下面是書中的一個示例程式碼,展示了命名對程式碼質量的提升

寫出整潔的程式碼,是每個程式設計師的追求

避免誤導

不要掛羊頭賣狗肉

不要覆蓋慣用縮略語

這裡不得不吐槽前兩天才看到的一份程式碼,居然使用了 l 作為變數名;而且,user居然是一個list(單複數都沒學好!!)

有意義的區分

程式碼是寫給機器執行,也是給人閱讀的,所以概念一定要有區分度

寫出整潔的程式碼,是每個程式設計師的追求

使用讀的出來的單詞

如果名稱讀不出來,那麼討論的時候就會像個傻鳥

使用方便搜尋的命名

名字長短應與其作用域大小相對應

避免思維對映

比如在程式碼中寫一個temp,那麼讀者就得每次看到這個單詞的時候翻譯成其真正的意義

註釋

有表達力的程式碼是無需註釋的。

The proper use of comments is to compensate for our failure to express ourself in code。

註釋的適當作用在於彌補我們用程式碼表達意圖時遇到的失敗,這聽起來讓人沮喪,但事實確實如此。The truth is in the code, 註釋只是二手資訊,二者的不同步或者不等價是註釋的最大問題。

書中給出了一個非常形象的例子來展示:用程式碼來闡述,而非註釋

寫出整潔的程式碼,是每個程式設計師的追求

因此,當想要添加註釋的時候,可以想想是否可以透過修改命名,或者修改函式(程式碼)的抽象層級來展示程式碼的意圖。

當然,也不能因噎廢食,書中指出了以下一些情況屬於好的註釋

法務資訊

對意圖的註釋,為什麼要這麼做

警示

TODO註釋

放大看似不合理之物的重要性

其中個人最贊同的是第2點和第5點,做什麼很容易透過命名錶達,但為什麼要這麼做則並不直觀,特別涉及到專業知識、演算法的時候。另外,有些第一感覺“不那麼優雅”的程式碼,也許有其特殊願意,那麼這樣的程式碼就應該加上註釋,說明為什麼要這樣,比如為了提升關鍵路徑的效能,可能會犧牲部分程式碼的可讀性。

最壞的註釋就是過時或者錯誤的註釋,這對於程式碼的維護者(也許就是幾個月後的自己)是巨大的傷害,可惜除了code review,並沒有簡單易行的方法來保證程式碼與註釋的同步。

函式

函式的單一職責

一個函式應該只做一件事,這件事應該能透過函式名就能清晰的展示。判斷方法很簡單:看看函式是否還能再拆出一個函式。

函式要麼做什麼do_sth, 要麼查詢什麼query_sth。最噁心的就是函式名錶示只會query_sth, 但事實上卻會do_sth, 這使得函式產生了副作用。比如書中的例子

寫出整潔的程式碼,是每個程式設計師的追求

函式的抽象層級

每個函式一個抽象層次,函式中的語句都要在同一個抽象層級,不同的抽象層級不能放在一起。比如我們想把大象放進冰箱,應該是這個樣子的:

頂部