建议9：习惯重载运算符在开发过程中，应该习惯于使用微软提供给我们的语法特性。我想每个人都喜欢看到这样的语法特性：intx=1;inty=2;inttotal=x+y; 而不是用下面的语法来完成一样的事情：intx=1;inty=2;inttotal=int.Add(x,y); 同理，在构...

 建议8：避免给枚举类型的元素提供显式的值一般情况下，没有必要给枚举类型的元素提供显式的值。创建枚举的理由之一，就是为了代替使用实际的数值。不正确地为枚举类型的元素设定显式的值，会带来意想不到的错误。如果为建议7中的枚举类型Week增加一个元素，代码如下所示：enumWeek{Monday=1,Tuesday...

 建议7：将0值作为枚举的默认值允许使用的枚举类型有byte、sbyte、short、ushort、int、uint、long和ulong。应该始终将0值作为枚举类型的默认值。不过，这样做不是因为允许使用的枚举类型在声明时的默认值是0值，而是有工程上的意义。试想，一个代表星期的枚举类Week，我们会想当然地认...

 建议6：区别readonly和const的使用方法很多初学者分不清readonly和const的使用场合。在我看来，要使用const的理由只有一个，那就是效率。但是，在大部分应用情况下，“效率”并没有那么高的地位，所以我更愿意采用readonly，因为readonly赋予代码更多的灵...

 建议5：使用int?来确保值类型也可以为null基元类型为什么需要为null？考虑两个场景：1）数据库中一个int字段可以被设置为null。在C#中，值被取出来后，为了将它赋值给int类型，不得不首先判断一下它是否为null。如果将null直接赋值给int类型，会引发异常。2）在一个分布式系统中，服务器需要...

 建议4：TryParse比Parse好如果注意观察除string外的所有基元类型，会发现它们都有两个将字符串转型为本身的方法：Parse和TryParse。以类型double为例，这两个方法最简单的原型为：publicstaticdoubleParse(strings)publicstaticboolTry...

 建议3：区别对待强制转型与as和is在阐述本建议之前，首先需要明确什么是强制转型，以及强制转型意味着什么。从语法结构上来看，类似下面的代码就是强制转型。secondType = (SecondType)firstType; 但是，强制转型可能意味着两件不同的事情：1）First...

 建议2：使用默认转型方法除了字符串操作外，程序员普遍会遇到的第二个问题是：如何正确地对类型实现转型。在上一个建议中，从int转型为string，我们使用了类型int的ToString方法。在大部分情况下，当需要对FCL提供的类型进行转型时，都应该使用FCL提供的转型方法。这些转型方法包括：使用类型的转换运算...

 最近拜读了陆敏技老师的《编写高质量代码改善C#程序的157个建议》，感觉不错，决定把笔记整理一遍。建议1：正确操作字符串字符串应该是所有编程语言中使用最频繁的一种基础数据类型。如果使用不慎，我们就会为一次字符串的操作所带来的额外性能开销而付出代价。本条建议将从两个方面来探讨如何规避这类性能开销：确保尽量少的...

 建议157：从写第一个界面开始，就进行自动化测试 如果说单元测试是白盒测试，那么自动化测试就是黑盒测试。黑盒测试要求捕捉界面上的控件句柄，并对其进行编码，以达到模拟人工操作的目的。具体的自动化测试请学习CodeUIAutomation，这里不再介绍。 转自：《编写高质量代码改善C#程序的...

 建议156：利用特性为应用程序提供多个版本基于如下理由，需要为应用程序提供多个版本：应用程序有体验版和完整功能版。应用程序在迭代过程中需要屏蔽一些不成熟的功能。假设我们的应用程序共有两类功能：第一类功能属于单机版，而第二类的完整版还提供了在线功能。那么，在功能上，需要定制两个属性“ONLINE&...

 建议155：随生产代码一起提交单元测试代码首先提出一个问题：我们害怕修改代码吗？是否曾经无数次面对乱糟糟的代码，下决心进行重构，然后在一个月后的某个周一，却收到来自测试版的报告：新的版本，没有之前的版本稳定，性能也更差了，Bug似乎也变多了。也就是说，重构的代码看上去质量更高了，可实际测试结果却不如人意。几...

 建议154：不要过度设计，在敏捷中体会重构的乐趣有时候，我们不得不随时更改软件的设计：如果项目是针对某个大型机构的，不同级别的软件使用者，会提出不同的需求，或者随着关键岗位人员的更替，需求也会随个人意志有所变更。如果竞争对手增加了新需求，我们也不得不为正在研发的新产品调整设计方案。刚开始的架构太糟糕了，这可...

 建议153：若抛出异常，则必须要注释有一种必须加注释的场景，即使异常。如果API抛出异常，则必须给出注释。调用者必须通过注释才能知道如何处理那些专有的异常。通常，即便良好的命名也不可能告诉我们方法会抛出那些异常，在这种情况下，使用注释是最好的手段。///<summary>///注释///<...

 建议152：最少，甚至是不要注释以往，我们在代码中不写上几行注释，就会被认为是钟不负责任的态度。现在，这种观点正在改变。试想，如果我们所有的命名全部采用有意义的单词或词组，注释还有多少存在的价值。即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新，有时候我们可能会在修改代码后忘记更...