建议155：随生产代码一起提交单元测试代码 首先提出一个问题：我们害怕修改代码吗？是否曾经无数次面对乱糟糟的代码，下决心进行重构，然后在一个月后的某个周一，却收到来自测试版的报告：新的版本，没有之前的版本稳定，性能也更差了，Bug似乎也变多了。也就是说，重构的代码看上去质量更高了，可实际测试结果却不 ...
建议157：从写第一个界面开始，就进行自动化测试 如果说单元测试是白盒测试，那么自动化测试就是黑盒测试。黑盒测试要求捕捉界面上的控件句柄，并对其进行编码，以达到模拟人工操作的目的。具体的自动化测试请学习Code UI Automation，这里不再介绍。 转自：《编写高质量代码改善C#程序的157个 ...
建议150：使用匿名方法、Lambda表达式代替方法 方法体如果过小（如小于3行），专门为此定义一个方法就会显得过于繁琐。比如： 上面的代码中，SampleMethod方法需要完成的功能是查看list中有没有长度等于5的元素。Predicate是一个委托，它接收元素值，并返回元素是否符合要求这一结果 ...
建议156：利用特性为应用程序提供多个版本 基于如下理由，需要为应用程序提供多个版本： 应用程序有体验版和完整功能版。 应用程序在迭代过程中需要屏蔽一些不成熟的功能。 假设我们的应用程序共有两类功能：第一类功能属于单机版，而第二类的完整版还提供了在线功能。那么，在功能上，需要定制两个属性“ONLIN ...
建议141：不知道该不该用大括号时，就用 如果if条件语句只有一行语句，要不要使用大括号？ 答案是：建议使用。一个括号不会增加多少代码，但是却让代码看上去增加了一致性。括号本身只会让代码更具条理性。 转自：《编写高质量代码改善C#程序的157个建议》陆敏技 ...
建议136：优先使用后缀表示已有类型的新版本 加后缀在某些情况下是很奇怪的形式，我们都不愿意看到OrderProcessor2这样的类型。但是，有的时候仍旧有必要这样做。最典型的是FCL中关于数字证书操作的X509Certificate和X509Certificate2这两个类型。 X509Cert ...
建议154：不要过度设计，在敏捷中体会重构的乐趣 有时候，我们不得不随时更改软件的设计： 如果项目是针对某个大型机构的，不同级别的软件使用者，会提出不同的需求，或者随着关键岗位人员的更替，需求也会随个人意志有所变更。 如果竞争对手增加了新需求，我们也不得不为正在研发的新产品调整设计方案。 刚开始的架 ...
建议149：使用表驱动法避免过长的if和switch分支 随着代码变得复杂，我们很容易被过长的if和switch分支困扰。 一个类枚举类型Week如下： 如果要把Week的元素值用中文输出，简单而丑陋的方法也许是封装一个GetChineseWeek方法： 之所以说这种方法太丑陋，是因为： 1）分支太 ...
建议133：用camelCasing命名私有字段和局部变量 私有变量和局部变量只对本类型负责，它们在命名方式也采用和开放的属性及字段不同的方法。camelCasing很适合这类命名。 camelCasing和PascalCasing的区别是它的首字母是小写的。之所以要采用这两种不同的命名规则，是为了 ...
建议134：有条件地使用前缀 在.NET的设计规范中，不建议使用前缀。但是，即便是微软自己依然广泛的使用这前缀。 最典型的前缀是m_，这种命名一方面是考虑到历史沿革中的习惯问题，另一方面也许我们确实有必要这么做。 在一个不是很庞大的类型中，我们确实不应该使用任何前缀。各类设计规范也总建议我们保持一个 ...
