一、要提高的代碼的可讀性，可以從以下幾方面努力

1、 清晰地表達意圖

2、好的變量、方法、類名

3、 一個變量、類、方法只做一件事

4、 同一個方法體內，保持相同的抽象層次

5、一致的縮進，一致的格式

6、 不要重復自己（避免手動的復制與粘貼代碼）

7、 減少“語法噪音”

8、減少代碼中的嵌套級別

9、 命名時取有意義的名字，避免不規范的縮寫

二、具體的提高代碼的可讀性的做法

1、先寫注釋，再寫代碼；理清思路再動手

（1）清晰的思路是編程行動的良好指南

花點時間思考一下，不要一接到任務就動手編代碼，從而陷入技術細節不可自拔

例如

C# 代碼   復制

//功能說明：XXX

PRivate void MyMainFunction()

{

//第一步，XXX

//第二步，XXX

MySubFunction ();//實現XXX

//第三步，XXX

}

//功能說明：XXX

private void MySubFunction()

{

}

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

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

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

通過主函數的運行效果，可以實時檢測子函數編寫的正確與否。我們編寫的子函數都即時被應用場景所調用，也就是即時的被測試，這不也是測試驅動的思想嗎？事實證明，這樣得到的函數，比預先設計的函數更有用。這樣，只要思路清晰正確，編程就不會走太大彎路。

（4）注釋應先于代碼存在，而不是編寫完代碼之后去補注釋。

因為人固有的懶惰，編寫完代碼之后都不情愿再去主動加注釋，這使得代碼的可讀性變差。

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

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

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

2、.給變量起個好名字

 
合理的變量命名是代碼可讀的基礎。好的命名，不僅僅是使得代碼易讀，它代表了你對業務領域的理解，對程序邏輯的認知，對項目框架的把握。所以，好的程序員很多時候糾結的不是技術實現問題，而是如何為變量起一個好名字，使得代碼讀起來流暢，能讓更多的人理解！
 
遵循一些成熟的命名規范，給變量起個好名字的事會容易一些。接下來，我們探討一下常見的命名規范問題。

 
（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生成的事件函數名字并沒完全遵守不使用下劃線的約定。
 
命名規范不是一成不變的，在特定場景下可以有自己風格的約定，前提是要使代碼保持一致、易讀。比如，一般我們強烈反對使用漢語拼音命名變量，可是在有些項目中，特別是涉及國內政府、院校的信息標準時，其數據庫字段（量很大）完全是按漢語拼音首字母制定的，如果非要翻譯成英文就有點矯枉過正了（工作量本身也很大）。一旦熟悉了這個行業之后，這些漢語拼音簡寫也就成了業務領域知識的一部分了，也就不那么別扭了，這也算中國特色吧。

 
3、如何檢測你的代碼是否規范

 
（1）人工檢測：讓同伴閱讀你的代碼（結對編程，代碼復審），發現問題。自我檢測，不懈追求――“讓人閱讀你的代碼，就像閱讀文章一樣流暢！”。
 
（2）工具檢測：FxCop，微軟的一個開發工具，可以對編譯過的托管代碼進行分析，并告訴用戶哪些地方不符合設計規范。

4、重構你的代碼，做得更好一點點！

 
嗅嗅代碼的壞味道：如果你發現在單頁中寫了過多的MySubFunction，如果你檢測到不符合設計規范的代碼，如果你寫了過長的函數，如果你發現你在重復拷貝相同的代碼段&hellip;…是時候重構你的代碼了！
 
何謂重構？重構是對軟件內部結構的一種調整，目的是在不改變軟件可察行為的前提下，提高其可理解性，降低其修改成本。
 
為何重構？改進軟件設計（消除重復，Don’t Repeat Yourself）；使代碼更易理解（提高可讀性）；幫你找到Bug（Keep Your Code Clean）；助你提高編程速度（后退是為了大踏步的前進）。
 
何時重構？三次法則：事不過三，三則重構。重構不是重構的目的，當重構能幫助你把后續的事情做得更好，那么還等什么？重構的時機：添加功能時，修補錯誤時，復審代碼時。
 
如何重構？小步前進，不斷驗證。

 
常見的重構原因和對策：
 
（1）代碼重復。提取為公共類/函數。
 
（2）代碼形式重復。考慮模板類/泛型。
 
（3）過多函數的類。考慮使用partial分部類，將類分拆到多個文件中去，每個分部類對應一個文件。如MVC中Controller類往往會成為包含過多Action函數的類，就可將其按功能域拆分為多個分部類。
 
（4）過長的參數列表。構造一個對象，包含所有要用的參數，然后將這個對象當作參數即可。
 
編程的過程實際是一個不斷重構（改進）的過程。通過不斷重構，可以去除代碼的壞味道，編寫可讀性更好的代碼。同時也深化了你對設計的理解，提高了你的編程素養。
 
重構，是一種生活態度，每天做得更好一點點。不要有過多的期望，一點點就好！不斷前進，逐步逼近完美。
 

5、向微軟學習，向MSDN學習！
 
微軟作為業界最為成功的軟件生產商，在各方面都有值得我們學習的地方。我覺得Windows、Office等是我們做界面和為用戶設計操作模式的最好老師，當我沒有思路的時候，我都會打開Windows的某個功能看看，就會受到啟發。
 
MSDN是我們學習編程的最好老師。MSDN是眾多大師的智慧結晶。經常看MSDN中的類庫，不僅可以系統的掌握類庫的功能，還可以學到如何給變量命名，如何進行架構設計等。看MSDN中的示例代碼，也是快速上手的捷徑；特別是一些“快速指南”，能很快讓你了解某個方面的開發技術。