一、要提高的代码的可读性，可以从以下几方面努力
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中的示例代码，也是快速上手的捷径；特别是一些“快速指南”，能很快让你了解某个方面的开发技术。