輕鬆提高代碼可讀性，看完你也可以寫出優秀代碼！

注意:這篇文章是講解代碼可讀性方面的一些寫法優化,而不是指的性能優化。

下面是我總結的一份思維導圖,方便形成對文章內容結構的一個大致的印象。

首先是關於代碼優化的幾條原則:

易讀性優先

如果不是性能瓶頸問題,不要只是為了性能優化而改寫代碼

沒有銀彈。無論怎麼寫,代碼的複雜性不會消失。

對於第三條，如果功能邏輯很簡單，三言兩語可以說清楚，那就肯定不需要幾百行代碼來完成，代碼簡簡單單就可以完成了。如果你這個功能邏輯很複雜，10分鐘內也沒辦法講清楚的功能，那麼代碼也會體現出功能的複雜。

一、如何命名代碼

程序員的三大難題

變數命名

緩存失效

循環邊界

這裡講的是程序員的三大難題之一,變數命名。

包括兩大點:

要注意詞性。

注意一致性(風格統一)。

注意詞性

普通變數

布爾變數命名,用「isX」或者「hasX」或者「canX」

函數變數

回調函數變數。用「介詞」開頭，或用「動詞的現在完成時態」

這兩種寫法都很容易讀,但是注意你最好只選擇一種風格寫法並保持,這也是下面將要提到的一致性。

特殊的情況 : 一些容易混淆的變數,可以添加前綴來讓他們更容易讀

特殊的情況 :屬性訪問器函數,可以用名詞

注意一致性(風格統一)

介詞一致性

如果你使用了 before + after，那麼就在代碼的所有地方都堅持使用

如果你使用了 before + 完成時，那麼就堅持使用

如果你改來改去，就「不一致」了，不一致將導致「不可預測」

順序一致性

比如 updateContainerWidth 和 updateHeightOfContainer 的順序就令人很彆扭，同樣會引發「不可預測」

表裡一致性

函數名稱正確的描述函數體內容,函數內容要體現函數名稱，既不能多也不能少。

比如：

這就是表裡不一，正確的寫法是:

要麼糾正函數名

要麼寫成兩個函數

時間一致性

隨著時間推移,業務的改變可能導致當初的變數名稱已經不再合適,這時候要及時修改,這也是最難做到的,因為牽一髮而動全身。

二、如何組織代碼

現在我們的變數名稱已經易讀,容易理解了,之後幹嘛?

是不是就剩下將你的變數組織起來了?

下面從兩個經典的方法講下如何組織你的代碼

1.用函數優化你的代碼

步驟：

將一坨代碼放到一個函數里

將代碼依賴的外部變數作為參數

將代碼的輸出作為函數的返回值

給函數取一個合適的名字

調用這個函數並傳入參數

這個函數里的代碼如果超過 5 行，則依然有優化的空間，請回到第 1 步

2.用對象組織你的代碼

我們會用 this 來串聯這個對象和所有函數。

還有一些需要注意的地方

一些固定套路

表驅動編程（《代碼大全》里說的）

所有一一對應的關係都可以用表來做

自說明代碼（以 API 參數為例）

把別人關心的東西放在顯眼的位置

bad smell（壞味道）

有些代碼可以用，但是很「臭」。

哪些代碼是有壞味道的

表裡不一的代碼

過時的注釋

邏輯很簡單，但是看起來很複雜的代碼

重複的代碼

相似的代碼

總是一起出現的代碼

最後

做好了這幾步，你的代碼就可以變得更加優秀，可讀性也大大提高起來。今天的前端開發工程師必備教程就講到這裡，大家如果要做開發，一定要做到一點：

但凡是經過你手的代碼，都會比之前好一點。

如果覺得有用，記得要關注點贊轉發留言哦！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！