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

避免預先設計的代碼

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

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

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

IDE 重構 vs 手工重構

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

手工重構QQ號碼拍賣代碼，意味著風險。如果沒有測試，直接對代碼進行重構，那么就會生不如死。

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

短、平的函數

編寫函數的時候，要注意長度要短~、一個函數完成一件事，并且避免多級嵌套。

長的函數，閱讀體驗不好。多層嵌套的函數，復雜度過高。

采用各種 Lint 來限制函數的長度、層嵌套的數量，是一種頗為有效的降低復雜度的方式。

適當的設計模式與原則

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

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

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

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

命名而非注釋

命名，對于程序員來說，是一個難題。

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

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

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

結論

你還有哪些奇技淫巧呢？

總結

以上是生活随笔為你收集整理的五个简单的原则，带你写出整洁代码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。