摘要：
直接上代码 阅读全文
摘要：
1. 概述 我们创建某一个对象需要很大的消耗，而这个对象在运行过程中又不一定用到，为了避免每次运行都创建该对象，这时候延迟初始化（也叫延迟实例化）就出场了。 延迟初始化出现于.NET 4.0，主要用于提高性能，避免浪费计算，并减少程序内存要求。也可以称为，按需加载。 2. 基本语法 3. 举例实现 阅读全文
摘要：
建议157：从写第一个界面开始，就进行自动化测试 如果说单元测试是白盒测试，那么自动化测试就是黑盒测试。黑盒测试要求捕捉界面上的控件句柄，并对其进行编码，以达到模拟人工操作的目的。具体的自动化测试请学习Code UI Automation，这里不再介绍。 转自：《编写高质量代码改善C#程序的157个 阅读全文
摘要：
建议156：利用特性为应用程序提供多个版本 基于如下理由，需要为应用程序提供多个版本： 应用程序有体验版和完整功能版。 应用程序在迭代过程中需要屏蔽一些不成熟的功能。 假设我们的应用程序共有两类功能：第一类功能属于单机版，而第二类的完整版还提供了在线功能。那么，在功能上，需要定制两个属性“ONLIN 阅读全文
摘要：
建议155：随生产代码一起提交单元测试代码 首先提出一个问题：我们害怕修改代码吗？是否曾经无数次面对乱糟糟的代码，下决心进行重构，然后在一个月后的某个周一，却收到来自测试版的报告：新的版本，没有之前的版本稳定，性能也更差了，Bug似乎也变多了。也就是说，重构的代码看上去质量更高了，可实际测试结果却不 阅读全文
摘要：
建议154：不要过度设计，在敏捷中体会重构的乐趣 有时候，我们不得不随时更改软件的设计： 如果项目是针对某个大型机构的，不同级别的软件使用者，会提出不同的需求，或者随着关键岗位人员的更替，需求也会随个人意志有所变更。 如果竞争对手增加了新需求，我们也不得不为正在研发的新产品调整设计方案。 刚开始的架 阅读全文
摘要：
建议153：若抛出异常，则必须要注释 有一种必须加注释的场景，即使异常。如果API抛出异常，则必须给出注释。调用者必须通过注释才能知道如何处理那些专有的异常。通常，即便良好的命名也不可能告诉我们方法会抛出那些异常，在这种情况下，使用注释是最好的手段。 转自：《编写高质量代码改善C#程序的157个建议 阅读全文
摘要：
建议152：最少，甚至是不要注释 以往，我们在代码中不写上几行注释，就会被认为是钟不负责任的态度。现在，这种观点正在改变。试想，如果我们所有的命名全部采用有意义的单词或词组，注释还有多少存在的价值。 即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新，有时候我们可能会在修改 阅读全文
摘要：
建议151：使用事件访问器替换公开的事件成员变量 事件访问器包含两部分内容：添加访问器和删除访问器。如果涉及公开的事件字段，应该始终使用事件访问器。代码如下所示： 使用事件访问器的好处是，提供对赋值更多细粒度的控制。这就好比应该使用属性而不使用字段一样。所以下面的代码没有事件访问器灵活： 转自：《编 阅读全文
摘要：
建议150：使用匿名方法、Lambda表达式代替方法 方法体如果过小（如小于3行），专门为此定义一个方法就会显得过于繁琐。比如： 上面的代码中，SampleMethod方法需要完成的功能是查看list中有没有长度等于5的元素。Predicate是一个委托，它接收元素值，并返回元素是否符合要求这一结果 阅读全文