自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

如何寫出讓別人能讀懂的代碼

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

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

我前幾天看了一本書,書中有這么一句話:

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

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

我們所寫的代碼除了讓機(jī)器執(zhí)行外,還需要別人來閱讀。所以我們要寫:

讓別人能讀懂的代碼

可擴(kuò)展的代碼

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

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

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

一.DRY(Don't repeat yourself)

此原則如此重要,簡單來說是因?yàn)椋?/p>

代碼越少,Bug也越少

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

二.TED原則

簡潔(Terse)

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

只做一件事(Do one thing)

三.舉例說明

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

反例:

  1. /// <summary> 
  2. /// !@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*(( 
  3. /// </summary> 
  4. /// <returns></returns> 
  5. public decimal GetCash() 
  6. //!@#$%^&^&*((!@#$%^&^&*(( 
  7. var a = new List<decimal>() { 2m, 3m, 10m }; 
  8. var b = 2
  9. var c = 0m; 
  10. //!@#$%^&^&*((!@#$%^&^&*((!@#$%^&^&*(( 
  11. foreach (var p in a) 
  12. c += p*b; 
  13. return c; 

重構(gòu)后:

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

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

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

2. 為布爾變量賦值

反例:

  1. public bool IsAdult(int age) 
  2. bool isAdult; 
  3. if (age > 18
  4. isAdult = true
  5. else 
  6. isAdult = false
  7. return isAdult; 

重構(gòu)后:

  1. public bool IsAdult(int age) 
  2. var isAdult = age > 18
  3. return isAdult; 

3.雙重否定的條件判斷

反例:

  1. if (!isNotRemeberMe) 
  2.  

重構(gòu)后:

  1. if (isRemeberMe) 
  2.  

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

4.拒絕HardCode,拒絕挖坑

反例:

  1. if (carName == "Nissan"
  2.  

重構(gòu)后:

  1. if (car == Car.Nissan) 
  2.  

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

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

反例:

  1. if (age > 18
  2.  

重構(gòu)后:

  1. const int adultAge = 18
  2. if (age > adultAge) 
  3.  

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

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

反例:

  1. if (job.JobState == JobState.New 
  2. || job.JobState == JobState.Submitted 
  3. || job.JobState == JobState.Expired 
  4. || job.JobTitle.IsNullOrWhiteSpace()) 
  5. //.... 

重構(gòu)后:

  1. if (CanBeDeleted(job)) 
  2. // 
  3.  
  4. private bool CanBeDeleted(Job job) 
  5. var invalidJobState = job.JobState == JobState.New 
  6. || job.JobState == JobState.Submitted 
  7. || job.JobState == JobState.Expired; 
  8. var invalidJob = string.IsNullOrEmpty(job.JobTitle); 
  9.  
  10. return invalidJobState || invalidJob; 

有沒有豁然開朗的趕腳?

7.嵌套判斷

反例:

  1. var isValid = false
  2. if (!string.IsNullOrEmpty(user.UserName)) 
  3. if (!string.IsNullOrEmpty(user.Password)) 
  4. if (!string.IsNullOrEmpty(user.Email)) 
  5. isValid = true

return isValid;

重構(gòu)后:

  1. if (string.IsNullOrEmpty(user.UserName)) return false
  2. if (string.IsNullOrEmpty(user.Password)) return false
  3. if (string.IsNullOrEmpty(user.Email)) return false
  4. return true

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

#p#

8.使用前置條件

反例:

  1. if (!string.IsNullOrEmpty(userName)) 
  2. if (!string.IsNullOrEmpty(password)) 
  3. //register 
  4. else 
  5. throw new ArgumentException("user password can not be empty"); 
  6. else 
  7. throw new ArgumentException("user name can not be empty"); 

重構(gòu)后:

  1. if (string.IsNullOrEmpty(userName)) throw new ArgumentException("user name can not be empty"); 
  2. if (string.IsNullOrEmpty(password)) throw new ArgumentException("user password can not be empty"); 
  3. //register 

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

9.參數(shù)過多,超過3個

反例:

  1. public void RegisterUser(string userName, string password, string email, string phone) 
  2.  

重構(gòu)后:

  1. public void RegisterUser(User user) 
  2.  

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

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

反例:

  1. public void RegisterUser(User user, bool sendEmail) 
  2.  

重構(gòu)后:

  1. public void RegisterUser(User user) 
  2.  
  3.  
  4. public void SendEmail(User user) 
  5.  

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

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

反例:

  1. private string CombineTechnicalBookNameOfAuthor(List<Book> books, string author) 
  2. var filterBooks = new List<Book>(); 
  3.  
  4. foreach (var book in books) 
  5. if (book.Category == BookCategory.Technical && book.Author == author) 
  6. filterBooks.Add(book); 
  7. var name = ""
  8. foreach (var book in filterBooks) 
  9. name += book.Name + "|"
  10. return name; 

重構(gòu)后:

  1. private string CombineTechnicalBookNameOfAuthor(List<Book> books, string author) 
  2. var combinedName = books.Where(b => b.Category == BookCategory.Technical) 
  3. .Where(b => b.Author == author) 
  4. .Select(b => b.Name) 
  5. .Aggregate((a, b) => a + "|" + b); 
  6.  
  7. return combinedName; 

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

四.關(guān)于DRY

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

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

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

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

責(zé)任編輯:chenqingxiang 來源: 博客園
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號