五個簡單的原則，帶你寫出整潔程式碼

每個人都有自己對於程式碼的看法，有自己的偏好。對於我來說，也是如此。作為一個實用主義者，我遵循的東西，比較少，也比較簡單。多了，記不住，也不實用。


避免預先設計的程式碼

架構往往得預先設計的，而程式碼容易被過度設計。而事先設計的架構，往往在落地的時候，會遇到一系列的挑戰。等到軟體交付時，則會變成新的架構，或者該架構的變體。程式碼，則也是類似的。

日常工作中，我們經常遇到的情況，到底有沒有必要提前編寫一些程式碼——這些功能往往是，我們根據以往經驗，猜測未來會有的功能？不事先編寫，那麼後期修改就比較麻煩。事先編寫的程式碼，不符合需求，那麼後期還是得重寫。只有運氣剛剛好，我們才能編寫出符合需要的程式碼。然而，多數時候，我們寫的這些程式碼往往是用不上的。

一旦程式碼中有大量多餘的程式碼，程式碼看上去就沒那麼整潔了。若非要在兩者做一個平衡，便是多做一點點，如先把介面準備好，但是不實現相應的功能。

IDE 重構 vs 手工重構

整潔的程式碼，意味著不重複，而每個人對於重複的定義是不一樣的。對於我來說，則是：事不過三，過三則重構。耦合和引數，會帶來新的複雜度。重構，不是一件容易的事，也不是一件太困難的事。

手工重構程式碼，意味著風險。如果沒有測試，直接對程式碼進行重構，那麼就會生不如死。

IDE 重構程式碼，則是依賴於 IDE 自帶的功能，以通過機器的方式來重構程式碼。與手工方式相比，它更加的可靠，並且風險相當的低。前提是，該語言有對應的 IDE 可以提供這個功能，如 WebStrom、Intellij IDEA 等。

短、平的函式

編寫函式的時候，要注意長度要短~、一個函式完成一件事，並且避免多級巢狀。

長的函式，閱讀體驗不好。多層巢狀的函式，複雜度過高。

採用各種 Lint 來限制函式的長度、層巢狀的數量，是一種頗為有效的降低複雜度的方式。

適當的設計模式與原則

設計模式和各種原則是好東西，它們可以方便我們與其他/她開發人員進行交流。當你遇到一個一對多的問題，別人一說，”你這個東西用觀察者模式來實現”，那麼問題就這麼解決了。

設計模式，是一系列對於相關問題的解決方案。缺少程式設計經驗的時候，學習設計模式，是一個不錯的提升方式。而問題的關鍵，在於如何在適當的時候使用它們。在這個過程中，我們經歷這麼一些情況：

• 不知道設計模式
• 拿著設計模式的錘子（定律），到處使用
• 對設計模式反感，會避免使用
• 自然而然的使用設計模式
  

程式語言在解決問題上是相通的，哪怕是不同正規化的設計語言，要解決的問題是一樣的，採用的設計模式也就類似。

命名而非註釋

命名，對於程式設計師來說，是一個難題。

一個好的變數名、函式名，遠遠比一行行註釋，更重要——程式碼是寫給人看的。

閱讀遺留系統程式碼的時候，最怕的不是又長又深的程式碼，而是程式碼中有個 42 這種魔法數字（magic number），又沒有對應的註釋。那怕得打出幾個電話、發幾十條資訊，才能知道這該死的 42 到底是什麼。

哪怕是使用錯誤的單詞，將 42 賦予這個變數，如 var ratio=42，也遠比 42 + 對應的註釋擁有更好的可讀性。特別是，如果到處是這個 42 的變數，只會使得到處都是相關的註釋。同樣的，這個問題，也出現在對於函式的命名上。好在我們對於函式的命名，會略微重視一些。

結論

你還有哪些奇技淫巧呢？

來源：phodal
原文：https://mp.weixin.qq.com/s/wmIDIdL4WZblrsXmxCbGfw