隨著軟件行業(yè)的不斷發(fā)展，歷史遺留的程序越來越多，代碼的維護(hù)成本越來越大，甚至大于開發(fā)成本。而新功能的開發(fā)又常常依賴于舊代碼，閱讀舊代碼所花費(fèi)的時(shí)間幾乎要大于寫新功能的代碼。

我前幾天看了一本書，書中有這么一句話：

“復(fù)雜的代碼往往都是新手所寫，只有經(jīng)驗(yàn)老道的高手才能寫出簡單，富有表現(xiàn)力的代碼”

此話雖然說的有點(diǎn)夸張，可是也說明了經(jīng)驗(yàn)的重要性。

我們所寫的代碼除了讓機(jī)器執(zhí)行外，還需要?jiǎng)e人來閱讀。所以我們要寫：

讓別人能讀懂的代碼

可擴(kuò)展的代碼

可測試的代碼(代碼應(yīng)該具備可測試性，對(duì)沒有可測試性的代碼寫測試，是浪費(fèi)生命的表現(xiàn))

其中2，3點(diǎn)更多強(qiáng)調(diào)的是面向?qū)ο蟮脑O(shè)計(jì)原則。而本文則更多關(guān)注于局部的代碼問題，本文通過舉例的方式，總結(jié)平時(shí)常犯的錯(cuò)誤和優(yōu)化方式。

本文的例子基于兩個(gè)指導(dǎo)原則：

一.DRY(Don't repeat yourself)

此原則如此重要，簡單來說是因?yàn)?#xff1a;

• 代碼越少，Bug也越少

• 沒有重復(fù)邏輯的代碼更易于維護(hù)，當(dāng)你修復(fù)了一個(gè)bug，如果相同的邏輯還出現(xiàn)在另外一個(gè)地方，而你沒意識(shí)到，你有沒有覺得自己很冤？

二.TED原則

• 簡潔(Terse)

• 具有表達(dá)力(Expressive)

• 只做一件事(Do one thing)

三.舉例說明

1.拒絕注釋，用代碼來闡述注釋

反例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

/// <summary> /// !@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*(( /// </summary> /// <returns></returns> public?decimal?GetCash() { //!@#$%^&^&*((!@#$%^&^&*(( vara =?new?List<decimal>() { 2m, 3m, 10m }; varb = 2; varc = 0m; //!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*(( foreach(var?p?in?a) { c += p*b; } returnc; }

重構(gòu)后：

1 2 3 4 5 6

public?decimal?CalculateTotalCash() { var?prices=new?List<decimal>(){2m,3m,10m}; var?itemCount = 2; return?prices.Sum(p => p*itemCount); }

良好的代碼命名完全可以替代注釋的作用，如果你正在試圖寫一段注釋，從某種角度來看，你正在試圖寫一段別人無法理解的代碼。

當(dāng)你無法為你的方法起一個(gè)準(zhǔn)確的名稱時(shí)，很可能你的方法不止做了一件事，違反了(Do one thing)。特別是你想在方法名中加入：And，Or，If等詞時(shí)

2. 為布爾變量賦值

反例：

1 2 3 4 5 6 7 8 9 10 11 12 13

public?bool?IsAdult(int?age) { bool?isAdult; if(age > 18) { isAdult =?true; } else { isAdult =?false; } return?isAdult; }

重構(gòu)后：

1 2 3 4 5

public?bool?IsAdult(int?age) { var?isAdult = age > 18; return?isAdult; }

3.雙重否定的條件判斷

反例：

1 2 3 4

if(!isNotRemeberMe) { }

重構(gòu)后：

1 2 3 4

if(isRemeberMe) { }

不管你有沒有見過這樣的條件，反正我見過。見到這樣的條件判斷，我頓時(shí)就暈了。

4.拒絕HardCode,拒絕挖坑

反例：

1 2 3 4

if(carName ==?"Nissan") { }

重構(gòu)后：

1 2 3 4

if(car == Car.Nissan) { }

既然咱們玩的是強(qiáng)類型語言，咱就用上編譯器的功能，讓錯(cuò)誤發(fā)生在編譯階段

5.拒絕魔數(shù)，拒絕挖坑

反例：

1 2 3 4

if(age > 18) { }

重構(gòu)后：

1 2 3 4 5

constintadultAge = 18; if(age > adultAge) { }

所謂魔數(shù)(Magic number)就是一個(gè)魔法數(shù)字，讀者完全弄不明白你這個(gè)數(shù)字是什么，這樣的代碼平時(shí)見的多了

6.復(fù)雜的條件判斷

反例：

1 2 3 4 5 6 7

if(job.JobState == JobState.New || job.JobState == JobState.Submitted || job.JobState == JobState.Expired || job.JobTitle.IsNullOrWhiteSpace()) { //.... }

重構(gòu)后：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

if(CanBeDeleted(job)) { // } privateboolCanBeDeleted(Job job) { var?invalidJobState = job.JobState == JobState.New || job.JobState == JobState.Submitted || job.JobState == JobState.Expired; va rinvalidJob =?string.IsNullOrEmpty(job.JobTitle); return?invalidJobState || invalidJob; }

有沒有豁然開朗的趕腳？

7.嵌套判斷

反例：

1 2 3 4 5 6 7 8 9 10 11 12

varisValid =?false; if(!string.IsNullOrEmpty(user.UserName)) { if(!string.IsNullOrEmpty(user.Password)) { if(!string.IsNullOrEmpty(user.Email)) { isValid =?true; } } } return?isValid;

重構(gòu)后：

1 2 3 4

if(string.IsNullOrEmpty(user.UserName))?return?false; if(string.IsNullOrEmpty(user.Password))?return?false; if(string.IsNullOrEmpty(user.Email))?return?false; return?true;

第一種代碼是受到早期的某些思想：使用一個(gè)變量來存儲(chǔ)返回結(jié)果。事實(shí)證明，你一旦知道了結(jié)果就應(yīng)該盡早返回。

8.使用前置條件

反例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

if(!string.IsNullOrEmpty(userName)) { if(!string.IsNullOrEmpty(password)) { //register } else { thrownewArgumentException("user password can not be empty"); } } else { thrownewArgumentException("user name can not be empty"); }

重構(gòu)后：

1 2 3

if(string.IsNullOrEmpty(userName))?thrownewArgumentException("user name can not be empty"); if(string.IsNullOrEmpty(password))?thrownewArgumentException("user password can not be empty"); //register

重構(gòu)后的風(fēng)格更接近契約編程，首先要滿足前置條件，否則免談。

9.參數(shù)過多，超過3個(gè)

反例：

1 2 3 4

public?void?RegisterUser(stringuserName,?stringpassword,?stringemail,?stringphone) { }

重構(gòu)后：

1 2 3 4

public?void?RegisterUser(User user) { }

過多的參數(shù)讓讀者難以抓住代碼的意圖，同時(shí)過多的參數(shù)將會(huì)影響方法的穩(wěn)定性。另外也預(yù)示著參數(shù)應(yīng)該聚合為一個(gè)Model

10.方法簽名中含有布爾參數(shù)

反例：

1 2 3 4

public?void?RegisterUser(User user,?bool?sendEmail) { }

重構(gòu)后：

1 2 3 4 5 6 7 8 9

public?void?RegisterUser(User user) { } public?void?SendEmail(User user) { }

布爾參數(shù)在告訴方法不止做一件事，違反了Do one thing

10.寫具有表達(dá)力的代碼

反例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

private?string?CombineTechnicalBookNameOfAuthor(List<Book> books,?string?author) { var?filterBooks =?newList<Book>(); foreach(va rbook?in?books) { if(book.Category == BookCategory.Technical && book.Author == author) { filterBooks.Add(book); } } varname =?""; foreach(var?book?in?filterBooks) { name += book.Name +?"|"; } returnname; }

重構(gòu)后：

1 2 3 4 5 6 7 8 9

private?string?CombineTechnicalBookNameOfAuthor(List<Book> books,?string?author) { varcombinedName = books.Where(b => b.Category == BookCategory.Technical) .Where(b => b.Author == author) .Select(b => b.Name) .Aggregate((a, b) => a +?"|"+ b); return?combinedName; }

相對(duì)于命令式代碼，聲明性代碼更加具有表達(dá)力，也更簡潔。這也是函數(shù)式編程為什么越來越火的原因之一。

四.關(guān)于DRY

平時(shí)大家重構(gòu)代碼，一個(gè)重要的思想就是DRY。我要分享一個(gè)DRY的反例：

項(xiàng)目在架構(gòu)過程中會(huì)有各種各樣的MODEL層，例如：DomainModel，ViewModel，DTO。很多時(shí)候這幾個(gè)Model里的字段大部分是相同的，于是有人就會(huì)想到DRY原則，干脆直接用一種類型，省得粘貼復(fù)制，來回轉(zhuǎn)換。

這個(gè)反例失敗的根本原因在于：這幾種Model職責(zé)各不相同，雖然大部分情況下內(nèi)容會(huì)有重復(fù)，但是他們擔(dān)當(dāng)著各種不同的角色。

考慮這種場景： DomainModel有一個(gè)字段DateTime Birthday{get;set;}，ViewModel同樣具有DateTime Birthday{get;set;}。需求升級(jí):要求界面不再顯示生日，只需要顯示是否成年。我們只需要在ViewModel中添加一個(gè)Bool IsAdult{get{return ....}}即可，DomainModel完全不用變化。

五.利用先進(jìn)的生產(chǎn)工具

以vs插件中的Reshaper為例，本文列舉的大部分反例，Reshaprer均能給予不同程度的提示。經(jīng)過一段時(shí)間的練習(xí)，當(dāng)Reshaper對(duì)你的代碼給予不了任何提示的時(shí)候，你的代碼會(huì)有一個(gè)明顯的提高。

截圖說明Reshaper的提示功能：

光標(biāo)移動(dòng)在波浪線處，然后Alt+Enter,Resharper 會(huì)自動(dòng)對(duì)代碼進(jìn)行優(yōu)化

如果你能夠避免本文總結(jié)的反例，你的代碼就已經(jīng)具備了優(yōu)秀代碼應(yīng)有的基因。當(dāng)然高質(zhì)量的代碼還需要良好的設(shè)計(jì)和遵循面向?qū)ο缶幊痰脑瓌t。 如果想了解更多相關(guān)內(nèi)容，請(qǐng)閱讀《代碼大全》，《代碼整潔之道》，《重構(gòu) 改善既有代碼的設(shè)計(jì)》，《敏捷軟件開發(fā) 原則、模式與實(shí)踐》。

總結(jié)

以上是生活随笔為你收集整理的写让别人能读懂的代码的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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