140，使用默认的访问修饰符。

如果不加访问修饰符，成员变量的默认是private的，类默认是internal的。为了明确访问的权限，我倒是建议都加上访问修饰符，这省不了多少代码。

141，不知道该不该加大括号的时候就加上。

大括号会多占用两行代码，到底一行语句的代码需不需要加大括号这是一个争论。但是为了避免引入不必要的bug还是加上吧。

142，总是提供有意义的命名。

我们不希望看到如iTemp的命名，类似于i的命名只应该出现在循环中。变量的命名应尽可能表达它应该表达的意思，不要太随意的命名，这会给代码维护制造困难。如果你不想维护糟糕的代码，那就从自己做起吧。

143，方法的抽象级别应该在同一层次上。

如：void LocalInit(){ RemoteInit();} void RemoteInit(){},LocalInit和RemoteInit应该是同一级别的，不应存在调用关系。可以做如下改进，void Init(){LocalInit();RemoteInit();}，现在它们的层次就一样了。

144，一个方法只做一件事。

这往往可以从方法的名字上判定方法是不是做了太多的事情，如果是，则考虑拆分成两个方法。

145，避免过长的方法和类。

方法的长度以前曾有人提过控制在50行，甚至更短的30行，这没有一个硬性的要求，原则就是要适合于阅读，我们一般以不超过显示器的一屏为佳。类的长度尽量在300行以内，如太大了可以考虑重构。

146，只对外公开必要的操作。

不要把所有的方法都设定为public，这会增加我们筛选方法的难度，同时也不建议曝露不必要的成员，不公开的成员就显示的设定为private是个好习惯。尽管默认也是private的。

147，重构多个相关属性为一个类。

这一步不是一上来就做的，而是重构的时候发现相关属性超过3个，就可以考虑提取了。

148，不重复代码。

重复代码给维护带来工作量和风险，修改了一处，而另一处没有得到修改。消除重复就能解决这个问题。

149， 使用表驱动法避免过长的if和switch分支。

如基于索引的表驱动，string[] chineseWeek = new string[] { "星期一", "星期二", "星期三", "星期四", "星期五", "星期六", "星期日" }; return chineseWeek[(int)w];

150， 使用匿名方法，Lambda表达式代替方法。

过小的函数体，如3行左右，可以考虑用Lambda表达式来进行简化。 超过3行以上的，可以提取成单独的方法，更利于阅读。

151， 使用事件访问器替换公开的事件成员变量。

public event ColumnClickEventHandler ColumnClick { add { this.Events.AddHandler(this, value); } remove { this.Events.RemoveHandler(this, value); }}，上面这段代码比public event ColumnClickEventHandler ColumnClick；有更好的灵活性，可以在add和remove中添加额外的逻辑。如果没有额外的逻辑控制，这样实现就显得多余，大多数情况都可以用后者。

152， 最少，最好不要写注释。

当所有的命名都能表达代码意图时，注释是多余的。如果功力不够，还是建议适量添加注释，至少要重构你代码的人也得看得懂你写的代码。

153， 如果代码抛出异常，则应该给出注释。

注释应该是xml，使用者通过查阅生成的帮助文档就知道要处理怎样的异常。

154， 不要过度设计，在敏捷中体会重构的乐趣。

155， 应该随生产代码一起提交测试代码。

写单体测试代码是必须的，时刻保持代码测试通过，我们才敢放心大胆的进行重构。如果没有它，随着代码维护的进行，新引入的bug就会越来越多。

156， 利用特性为应用程序提供不同的版本。

比如，我们的程序可能分为体验版和完整版，他们能使用的功能是不一样的，我们不可能去分别建立两个不同的程序，利用特性（Attribute）的功能就可以完成这种定制。对方法或类使用[Conditional("ONLINE")]特性，在文件的最顶部定义#define ONLINE，Conditional可以是复数的，即可以标明一个方法同时是ONLINE和OFFLINE的。我们还可以在工程的属性里定义ONLINE，OFFLINE使其对整个工程有效。

157， 从写第一个界面开始，就进行自动化测试。

这一点着重于UI的自动化测试。Code UI Automation是一个Vs自带的UI自动化测试工具，适当的时候应该学习学习。