• 整潔的代碼

• 有意義的命名

  • 函數(shù)命名

  • 變量命名

• 函數(shù)的定義

• 注釋的規(guī)范

• 代碼的長度

• 代碼的對齊

我寫代碼已經(jīng)有好幾年了，最近看了一本書叫做《代碼整潔之道》。我發(fā)現(xiàn)這本書中介紹的一些內(nèi)容對我來說非常有啟發(fā)性。書中提到的一些方法和技巧讓我重新審視了自己的代碼風格，讓我更加注重代碼的可讀性和可維護性。例如，書中提到了如何給變量和函數(shù)命名，編寫注釋和文檔，以及如何避免代碼重復等等。這些技巧和方法都非常實用，我會在今后的編程工作中盡可能地應(yīng)用它們來提高我的代碼質(zhì)量。?

整潔的代碼

來讓我們思考一個問題，什么樣的代碼才算是好代碼？

關(guān)于這一點我大概整理了一些自己的看法，羅列了之后如下所示：

準確性

可以通過測試用例，滿足具體應(yīng)用場景。

簡介性

沒有重復性的代碼，簡潔明了，沒有過多的繁瑣類的封裝，函數(shù)，方法。

看到這里，你可能會想，說起來很能理解，但是實際工作中又該如何注意呢？別急，我們來看下邊這個反面案例：

?

這段代碼是早期我在工作時所寫的一段支付代碼，在進行支付之前，先判斷購物車里的商品庫存是否充足，如果充足則進行扣減操作。但是現(xiàn)在回過頭來看這段代碼，你就會發(fā)現(xiàn)存在一些問題。

• 代碼優(yōu)化分析?首先上邊的代碼在業(yè)務(wù)含義上并沒有什么的問題，不過我們可以在代碼的精煉程度?上進行一些優(yōu)化。

對于參數(shù)校驗，購物車校驗，庫存校驗?，其實我們都可以加入一些類似于斷言組件之類的設(shè)計進行優(yōu)化。

另外一些對象構(gòu)建的代碼其實可以做一些封裝，因為調(diào)用這個接口的同事大多數(shù)時候都不會太愿意去關(guān)心這些參數(shù)的構(gòu)造過程，更多時候我們只需要將它封裝起來，然后通過一個函數(shù)的名字來告訴使用者就可以了。

進行優(yōu)化之后的代碼可以變成如下所示：

有意義的命名

函數(shù)命名

有的時候，我們對于函數(shù)的命名會有出現(xiàn)“名不副其實”的情況，例如下邊這個案例：

?

這段代碼中，返回的類型是Map類型，但是函數(shù)的命名卻以List結(jié)尾，這樣就給人有誤解的意思。如果函數(shù)的名字沒法給人很好的易讀性，就需要開發(fā)者再花費額外的時間趣深入理解，這就會顯得很費勁。再看下邊這個案例：?

在這個函數(shù)里面，會自動生成一個隨機數(shù)組，但是數(shù)字的值如果是負數(shù)，則會自動變?yōu)?。但是為什么我們不在函數(shù)命名中進行定義呢？例如定義命名為：getNonnegativeArr(int len), 這樣不是更好理解函數(shù)的意思嘛。

變量命名

對于函數(shù)變量的命名不要使用0或者o，1或者l很容易讓人看混，另外變量或者參數(shù)的命名也盡量使其具有意義，例如下邊這個案例所示：

例如這個案例中，參數(shù)命名采用了list1，list2，就很讓人容易誤解，不知道哪個參數(shù)是源集合，哪個參數(shù)是需要被比較的子集合。如果我們對它進行一些優(yōu)化，看起來的效果就會明顯不同，例如：?

使用好的變量命名可以讓人清晰了解到這個變量的類型是什么樣的，另外在定義一些具有特殊含義的變量時候可以結(jié)合下具體的業(yè)務(wù)場景。例如下邊這段代碼，需要分別計算工作日 和 周末的訂單流水金額總數(shù)，?

其實在這里我們可以賦予一個特殊的業(yè)務(wù)命名來表示，例如下邊這樣的寫法：?

相對于上邊的變量i,j寫法，這種具有業(yè)務(wù)含義的變量命名更加能讓人明確它的具體含義。

函數(shù)的定義

函數(shù)的命名

函數(shù)的命名盡量保證一個函數(shù)只做一件事的原則，不要參雜過多的其他業(yè)務(wù)操作。

函數(shù)的參數(shù)個數(shù)

通常參數(shù)的個數(shù)建議最多設(shè)置在3個左右，如果參數(shù)過多容易讓人看了有誤解，此時可以嘗試用一些類去進行封裝。

函數(shù)的參數(shù)命名

對于有共同含義的參數(shù)，我們可以將它命名到同一個變量中，這樣能夠通過業(yè)務(wù)領(lǐng)域去定義他們，方便識別。

對于參數(shù)的命名可以結(jié)合一些工作術(shù)語，例如當我們需要定義一個隊列參數(shù)的時候可以定義JobQueue。

再來看下邊這個案例，我們定義了一個用戶基礎(chǔ)屬性類：

在這個案例中的name，number，street，city字段分別表示了用戶所居住的信息，但是如果我們不加以注釋或者沒有了解的同事和使用者預(yù)先說明的話，這些字段的具體含義是很難看出來的。這種時候我們可以嘗試給它加上一些特殊的業(yè)務(wù)前綴來表示，例如下邊兩種寫法：?

不過更好的表示方式還是單獨設(shè)計一個對象來存儲這些具有明確業(yè)務(wù)含義的對象，例如定義一個Address對象來管理它們，例如下邊所示：?

注釋的規(guī)范

不要太依賴于注釋

關(guān)于代碼注釋方面，相信工作了一段時間的開發(fā)都會有以下想法：不太相信代碼注釋所寫的內(nèi)容。為什么會有這樣的想法呢？?我感覺主要原因還是和代碼的不斷迭代有關(guān)，隨著代碼的不斷改動，其內(nèi)部的流程早已經(jīng)和注釋表達的含義背道而馳。所以有時候我們代碼注釋的意義并不是特別大。

有時候如果代碼注釋和核心內(nèi)容不符的時候，它反而成了一段“謊言”的存在。所以我認為：唯一真正好的注釋是你要想辦法去不用寫注釋。

別寫廢話注釋

在我早期工作的時候，這個點確實經(jīng)常會犯，例如定義一個對象的時候，我?guī)缀鯐o每個字段都加入一行注釋，例如下邊這個類：

雖然說給每個字段都備注了注釋，看起來也似乎很規(guī)范，但是這樣的做法反而給人感覺寫了一堆廢話。通過每個字段的命名來看，難道它們還能有別的意思嘛？而且時間久了，別人看到這些無用的注釋之后也會自動過濾掉它們的含義。

代碼的長度

通常我們定義的一個類，其包含的代碼量不建議設(shè)計得太大，大部分都濃縮在500行以內(nèi)這個范圍就好了。這是因為通常短的內(nèi)容會比長的內(nèi)容更方便讓人理解，這就好比現(xiàn)如今的人更喜歡刷短視頻，但是對于一些長達幾十分鐘或者幾個小時的短片/電影卻沒有那么感興趣。

除了好閱讀之外，在實際工作中，大家如果使用的電腦配置不高，在電腦運行了很久的情況下再去用編輯器去修改一些篇幅非常大的類，反而會塌癟慢。（我試過用Idea打開一份3000+行數(shù)的代碼文件，挪動一格光標大概會有1秒的延遲）

另外，也并不是說代碼的長度越短越好，有時候適當?shù)目崭衽c換行可以增加代碼片段的可讀性。

代碼的對齊

在編寫代碼的時候，對于變量的對齊格式不同，其實也是有講究的。來看下邊兩組不同代碼的書寫風格：

變量的名稱統(tǒng)一對齊：

變量的類型統(tǒng)一對齊：?

在工作中，我更加會傾向于使用第二種書寫格式，因為它給我的感覺會讓人更加清晰看到對應(yīng)變量的格式類型是怎樣的。而對于第一種類型而言，給人感覺對于變量的類型不是那么地關(guān)注。

你們有哪些很好的代碼習慣，歡迎分享。

?文章來源地址http://www.zghlxwxcb.cn/news/detail-433556.html

?

?

?

?

?

?

?

?

到了這里，關(guān)于作為一名程序員，如何寫出一手讓同事膜拜的漂亮代碼？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！