一、要提高的代码的可读性，可以从以下几方面努力

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，如果你检测到不符合设计规范的代码，如果你写了过长的函数，如果你发现你在重复拷贝相同的代码段……是时候重构你的代码了！
 
何谓重构？重构是对软件内部结构的一种调整，目的是在不改变软件可察行为的前提下，提高其可理解性，降低其修改成本。
 
为何重构？改进软件设计（消除重复，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中的示例代码，也是快速上手的捷径；特别是一些“快速指南”，能很快让你了解某个方面的开发技术。

如何提高代码可读性