如何編寫可讀性好的代碼 如何編寫可讀性好的代碼

“讓人閱讀你的代碼，就像閱讀優美的文章一樣流暢！”——這就是好代碼！

把代碼當作一篇優美的散文來寫！用這樣的标準來要求自己，一定會寫出好代碼，一定會成為一個優秀的程式員。

代碼不僅是寫給機器編譯的，更是寫給人看的！

代碼不僅是代碼，更是文檔！

清晰的思路是程式設計行動的良好指南。花點時間思考一下，不要一接到任務就動手編代碼，進而陷入技術細節不可自拔。

我一般這樣程式設計：

（1）在一個空的函數體内用注釋寫出自己的思路，如：

//功能說明：XXX

private void MyMainFunction()

{

//第一步，XXX

//第二步，XXX

MySubFunction ();//實作XXX

//第三步，XXX

}

private void MySubFunction()

（2）理清思路後，在空白處填寫自己的代碼。

如果某個步驟中實作起來感覺有點麻煩，那就先放一個空的子函數，為這個子函數建一個空的函數體——保證編譯始終通過，稍後再填充這個空函數體。這種方法不影響你的整體思路，避免陷入程式設計細節，同時又讓“大事化小，小事化了”。

（3）編完主函數後，填充空的子函數體。

其實是對（1）（2）的疊代。通過主函數的運作效果，可以實時檢測子函數編寫的正确與否。我們編寫的子函數都即時被應用場景所調用，也就是即時的被測試，這不也是測試驅動的思想嗎？事實證明，這樣得到的函數，比預先設計的函數更有用。

這樣，隻要思路清晰正确，程式設計就不會走太大彎路。

注釋應先于代碼存在，而不是編寫完代碼之後去補注釋。因為人固有的懶惰，編寫完代碼之後都不情願再去主動加注釋，這使得代碼的可讀性變差。

因為大多數人都懶得加注釋，是以我對初學者一般會要求每五行要有一行注釋，總之是多多益善。矯枉必須過正！因為，減少注釋是一件容易的事。有人會擔心注釋過多的問題，可是至今我還沒有看到注釋過多的情況。

另外，利用空白或空白行合理分隔代碼，也是一種良好的注釋。就像好的文章印刷時，段落間距要大一點是一樣的。文章中也要留白！

使用region合理分隔代碼，同時在region中加入注釋。特别是，一定要把私有函數聚集到region中折疊起來，不要與公有函數（或事件函數）交叉，因為我們閱讀代碼往往是從公有函數（或事件函數）入手的。這可以隐藏細節，使代碼看起來更整潔。

合理的變量命名是代碼可讀的基礎。好的命名，不僅僅是使得代碼易讀，它代表了你對業務領域的了解，對程式邏輯的認知，對項目架構的把握。是以，好的程式員很多時候糾結的不是技術實作問題，而是如何為變量起一個好名字，使得代碼讀起來流暢，能讓更多的人了解！

遵循一些成熟的命名規範，給變量起個好名字的事會容易一些。接下來，我們探讨一下常見的命名規範問題。

（1）常見的大小寫命名法：

PascalCasing（大寫開頭）：用于名字空間、類型、成員等的命名，舉例：FileStream。

camelCasing（駝峰命名法，小寫開頭）：用于形參、局部變量、私有字段等的命名。舉例ToInt32(string value)。

匈牙利命名法（小寫開頭，首單詞為資料類型）：不推薦使用，因為IDE的智能提示很容易讓你知道變量的類型。舉例：intCount、iCount。

另外，微軟建議不要在單詞間使用下劃線。

（2）名字空間的命名：

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]。舉例：

XuanyuanTech.RailwayMis.Web

（3）類（結構）及對象的命名：

名詞或名詞短語，因為它們代表系統中的實體。舉例：

Student student;

List<Student> students;

（4）接口的命名：

表示類型層次的根基時：名詞或名詞短語，如：IList<T>；

表示某種能力時：形容詞或形容詞短語，如IComparable<T>。

（5）方法的命名：

動詞或動詞短語，DoSomething()。如：String.Split()

傳回布爾值時使用表示肯定性的短語，并考慮第三人稱。如：collection.Contains(item)

（6）屬性的命名：

名詞短語或形容詞。舉例：

public class ListView{

 public ItemCollection Items {get;}//這裡用複數形式

用肯定性短語命名布爾屬性，考慮字首“Is/Can/Has”。舉例：CanRead、IsPostBack。

（7）控件的命名：

在ASP.NET MVC程式設計中是不需要這項規範的。

在WinForm、ASP.NET WebForm程式設計中，我喜歡使用匈亞利命名法給操控型控件命名，操控型控件主要指菜單、按鈕、樹圖等。如menuFile、menuFile_Open分别表示一個一級和二級菜單，btnFile_Open表示一個按鈕，這也避免了菜單和按鈕功能相同時命名重複的尴尬。另外，如果你在IDE中輸入一個menu，所有的菜單控件會按字母順序在智能提示欄中整齊的排列顯示。IDE為按鈕menuFile自動生成的點選事件函數命名為private void menuFile_Click()，這比File_Click()更好了解，因為在這裡智能提示不能告訴你File是什麼東東。

在添加或編輯界面中，會有大量的編輯型控件（主要指文本框、下拉框等）與資料實體的屬性對應。這時我們可以考慮使用統一的字首e給這些控件命名，如編輯框eName對應實體對象的Name屬性，e在這裡可以了解為entity或edit。使用統一的字首e，為的就是在IDE中輸入字首後，其智能提示的内容與實體對象的屬性提示保持順序上的一緻，不被其它控件的名字插入而幹擾對應的一緻性。當然，如果使用自動化代碼生成工具，也可以考慮不使用字首。

這裡，我們較多的考慮了IDE（特别是智能提示）對程式設計的影響。同時我們也看到IDE生成的事件函數名字并沒完全遵守不使用下劃線的約定。

命名規範不是一成不變的，在特定場景下可以有自己風格的約定，前提是要使代碼保持一緻、易讀。比如，一般我們強烈反對使用漢語拼音命名變量，可是在有些項目中，特别是涉及國内政府、院校的資訊标準時，其資料庫字段（量很大）完全是按漢語拼音首字母制定的，如果非要翻譯成英文就有點矯枉過正了（工作量本身也很大）。一旦熟悉了這個行業之後，這些漢語拼音簡寫也就成了業務領域知識的一部分了，也就不那麼别扭了，這也算中國特色吧。

（1）人工檢測：讓同伴閱讀你的代碼（結對程式設計，代碼複審），發現問題。自我檢測，不懈追求――“讓人閱讀你的代碼，就像閱讀文章一樣流暢！”。

嗅嗅代碼的壞味道：如果你發現在單頁中寫了過多的MySubFunction，如果你檢測到不符合設計規範的代碼，如果你寫了過長的函數，如果你發現你在重複拷貝相同的代碼段……是時候重構你的代碼了！

何謂重構？重構是對軟體内部結構的一種調整，目的是在不改變軟體可察行為的前提下，提高其可了解性，降低其修改成本。

為何重構？改進軟體設計（消除重複，Don’t Repeat Yourself）；使代碼更易了解（提高可讀性）；幫你找到Bug（Keep Your Code Clean）；助你提高程式設計速度（後退是為了大踏步的前進）。

何時重構？三次法則：事不過三，三則重構。重構不是重構的目的，當重構能幫助你把後續的事情做得更好，那麼還等什麼？重構的時機：添加功能時，修補錯誤時，複審代碼時。

如何重構？小步前進，不斷驗證。（Done Better Than Perfect）

常見的重構原因和對策：

（1）代碼重複。提取為公共類/函數。

（2）代碼形式重複。考慮模闆類/泛型。

（3）過多函數的類。考慮使用partial分部類，将類分拆到多個檔案中去，每個分部類對應一個檔案。如MVC中Controller類往往會成為包含過多Action函數的類，就可将其按功能域拆分為多個分部類。

（4）過長的參數清單。構造一個對象，包含所有要用的參數，然後将這個對象當作參數即可。

程式設計的過程實際是一個不斷重構（改進）的過程。通過不斷重構，可以去除代碼的壞味道，編寫可讀性更好的代碼。同時也深化了你對設計的了解，提高了你的程式設計素養。

重構，是一種生活态度，每天做得更好一點點。不要有過多的期望，一點點就好！不斷前進，逐漸逼近完美。

微軟作為業界最為成功的軟體生産商，在各方面都有值得我們學習的地方。我覺得Windows、Office等是我們做界面和為使用者設計操作模式的最好老師，當我沒有思路的時候，我都會打開Windows的某個功能看看，就會受到啟發。

MSDN是我們學習程式設計的最好老師。MSDN是衆多大師的智慧結晶。經常看MSDN中的類庫，不僅可以系統的掌握類庫的功能，還可以學到如何給變量命名，如何進行架構設計等。看MSDN中的示例代碼，也是快速上手的捷徑；特别是一些“快速指南”，能很快讓你了解某個方面的開發技術。總之，看MSDN有百利而無一害，呵呵，比看很多爛書強多了。

MSDN是幫助文檔，我們在使用很多軟體遇到問題時，是否忽略了開發者精心給我們準備的幫助文檔呢？

---------------------

通過注釋理清思路，給變量起好名字，重構你的代碼，從MSDN中領悟大師真谛，其實都是一些程式設計習慣，養成好的、适合自己的習慣會受益終身。軟體大師Kent Beck說：

“我不是個偉大的程式員，我隻是個有着一些優秀習慣的程式員而已。”

——與諸君共勉！希望大家都成為具有優秀習慣的程式員，編寫散文詩一樣的代碼！

《.NET設計規範：約定、慣用法與模式》

《重構——改善既有代碼的設計》

本文隻是入門知識，未盡問題請參考這兩本書，呵呵J

 ---------------------

博友【麒麟.NET】推薦：《代碼整潔之道》

博友【PetterLiu】推薦：《The Art of Readable Code》（編寫可讀代碼的藝術）

補充推薦：

《簡約之美》

《黑客與畫家》

《實作模式》(Kent Beck)

夏春濤   

<a href="mailto:[email protected]">[email protected]</a>

http://SummerRain.cnblogs.com

2012年8月25日