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

避免預(yù)先設(shè)計的代碼

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

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

一旦代碼中有大量多余的代碼，代碼看上去就沒那么整潔了。若非要在兩者做一個平衡，便是多做一點(diǎn)點(diǎn)，如先把接口準(zhǔn)備好，但是不實(shí)現(xiàn)相應(yīng)的功能。

IDE 重構(gòu) vs 手工重構(gòu)

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

手工重構(gòu)QQ號碼拍賣代碼，意味著風(fēng)險。如果沒有測試，直接對代碼進(jìn)行重構(gòu)，那么就會生不如死。

IDE 重構(gòu)代碼，則是依賴于 IDE 自帶的功能，以通過機(jī)器的方式來重構(gòu)代碼。與手工方式相比，它更加的可靠，并且風(fēng)險相當(dāng)?shù)牡汀Ｇ疤崾?#xff0c;該語言有對應(yīng)的 IDE 可以提供這個功能，如 WebStrom、Intellij IDEA 等。

短、平的函數(shù)

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

長的函數(shù)，閱讀體驗(yàn)不好。多層嵌套的函數(shù)，復(fù)雜度過高。

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

適當(dāng)?shù)脑O(shè)計模式與原則

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

設(shè)計模式，是一系列對于相關(guān)問題的解決方案。缺少編程經(jīng)驗(yàn)的時候，學(xué)習(xí)設(shè)計模式，是一個不錯的提升方式。而問題的關(guān)鍵，在于如何在適當(dāng)?shù)臅r候使用它們。在這個過程中，我們經(jīng)歷這么一些情況：

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

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

命名而非注釋

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

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

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

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

結(jié)論

你還有哪些奇技淫巧呢？

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。