本书是C#程序员进阶修炼的必读之作，包含的全部都是C#编码的最佳实践，从语言本身、程序的设计和架构、编码规范和编程习惯等三大方面对C#程序员遇到的经典问题给出了经验性的解决方案，为C#程序员如何编写更高质量的C#代码提供了157条极为宝贵的建议。对于每一个问题，不仅以建议的方式给出了被实践证明为十分优秀的解决方案，而且还给出了经常被误用或被错误理解的不好的解决方案，从正反两个方面进行了分析和对比。
全书一共三个部分，第一部分专注于C#语言本身，一共89条建议，涵盖了C#语言基本要素、集合、LINQ、泛型、委托、事件、资源管理、序列化、异常处理、异步、多线程、任务和并行编程等与C#语法相关的核心内容；第二部分重点讲解了C#程序的设计和架构，一共32条建议，涉及成员设计、面向对象的类型设计、安全性设计等重要方面的内容；第三部分探讨了C#的编码规范及编程习惯，一共36条建议，包含C#命名规范、如何使代码更整洁以及如何规范开发行为等方面的内容。
本书是一本关于如何编写高质量C#代码的工具书，列举的问题非常典型，给出的建议也非常实用，其中的每一条建议都有可能在我们编写下一行代码的时候被用到。你可以将此书搁置在案头，以便有需要的时候随时查阅。
编写高质量代码
改善C#程序的157个建议
陆敏技 著
封面：
从语法、程序架构和设计、编码习惯和编程规范3个层面深入探讨编写高质量C#代码的技巧、禁忌和最佳实践
封底：
这是一本关于C#编码最佳实践的集大成之作，也是一本能指导C#程序员编写出高质量代码的指点迷津之作。全书从C#语法、程序的架构和设计、编码规范和编程习惯3大方面为广大的C#程序员们总结了157条极富借鉴价值的建议，这些建议都是在实践中被证明是解决C#编码中疑难问题的最佳实践。如果掌握本书中的内容，不仅能加深对C#语言的理解，以及提升程序架构和设计方面的能力，而且还能规范我们的开发行为和习惯，让我们成为一名优秀的程序员，让我们能编写出更高质量的代码。
—— 51CTO（www.51cto.com）
作为一名程序员，没有人愿意留下一堆糟糕的代码。如果我们编写的代码运行速度慢、消耗的内存多，而且还时不时地抛出一些莫名其妙的错误，我们一定会十分疑惑：我们的代码到底怎么了？问题很明显：我们编写的代码质量不高。本书从C#语言本身、程序的架构和设计、编码规范和编程习惯等3大方面就如何编写高质量的C#代码给出了大量的宝贵建议。如果能理解并熟练使用本书中的知识，我们不仅能在一定程度上避免糟糕的代码，而且还能大幅度提升编码水平。
—— 马伟 资深微软技术专家/ASP.NET MVP/畅销书《ASP.NET 4权威指南》作者
学习任何一门编程语言，入门一般都不难，难的是进阶和提高；让程序跑起来不难，难的是如何让程序跑得又快又好。作为一个程序员，我们在进阶的路上总会遇到各种各样的问题，有时候需要为这些问题付出代价，需要在不断试错和纠错中积累经验。很幸运的是，本书针对C#语法、程序的架构和设计、编码规范和编程习惯等3大方面给出了157条宝贵的建议，每一条建议都来自于实践和经验的总结，每一条建议都能帮你避免在编码时可能会犯的错误，实用性极强。强烈推荐！
—— 姜晓东 资深微软技术专家/畅销书《C# 4.0权威指南》作者
前：
也许大多数C#程序员都会在进阶的路上被以下几类问题所困扰：
一、来自于语言本身的问题。例如：
如何转型才是效率最高的？
闭包中有哪些陷阱？
如何在并行方法体中谨慎使用锁？
……
二、来自于程序架构和设计方面的问题。例如：
在进行成员设计时，为何要避免在构造方法中调用虚成员？
在进行类型设计时，为何要避免双相耦合？
在进行安全性设计时，如何使用SSL确保通信中的数据安全？
……
三、来自于编码习惯和编程规范方面的问题。例如：
为何事件处理器的命名应尽量采用组合方式？
为何建议使用匿名方法、lambda表达式代替方法？
随生产代码一起提交单元测试代码是一个好习惯吗？
……
如果你曾经或正在思考类似于这样的问题，说明你正在为写出更高质量的C#代码而努力。本书从上述3个方面对C#编码中的一些疑难和常见问题给出了经验性的解决方案，如果掌握本书中的内容，糟糕的代码将离我们更远一点，我们将离优秀更近一些。
作者简介
陆敏技 资深软件工程师、项目经理和架构师，从事软件开发工作近10年。尤其精通微软技术，对C#、WPF、WCF、ASP.NET和.NET技术有十分深入的研究，曾参与和主导了大量相关项目的架构和开发工作，积累了丰富的经验。此外，非常擅长分布式开发技术，而且有丰富的培训和授课经验。活跃于博客园等技术社区，乐于分享，有较高的知名度和社区影响力。
为什么写这本书
事实上，我在写本书之前就一直在思考一个问题：到底什么样的编程书籍能够帮助入门者快速进阶？所谓“入门者”指的是已经可以使用一门语言编写程序，但是不明白如何编写高质量代码的人。于是我开始回忆自己在开发生涯中的入门阶段，那时候，我常常被以下三类问题所困扰。第一类来自于语言本身，如：
如何格式化字符串才是最高效的？
基本类型间或其他CLR类型间的转换怎样才算是最高效的？
for和foreach有什么区别，何时该用for，何时该用foreach？
什么是Dispose模式，为什么要释放资源，如何释放资源？
多线程应选择何种方式来开启和结束，各线程之间为什么要同步，如何同步，如何锁定资源？
第二类来自于设计架构，如果你对编码充满热情，相信你的大脑里很快就会充满以下这些问题：
使用单例模式还是静态类，为什么有了静态类还需要单例模式？
该使用静态方法还是实例方法，它们的本质区别是什么？
如何使用异常才是最正确的，什么时候抛出异常，什么时候“吃掉”异常，为什么需要自定义异常？
如何避免过多的条件判断分支？
如何保证程序的数据安全和通信安全？
第三类问题最常见，可能来自于编码习惯和编程思想，我在入门阶段经常会问自己下面这些问题：
一个文件只包含一个类比较好，还是一个文件可以包含多个类？
如何命名才是专业级别的？
应该使用抽象类还是接口？
到底什么才是真正的面向对象编码，我这样编程够面向对象吗？
什么是单元测试，如何编写单元测试？
如果你也曾经问过自己类似的问题，说明你已经为成为专业程序员做好了准备；如果你还苦于找不到问题的答案，那么本书正是为你准备的。本书为那些普遍存在于初级开发者脑海中的问题给出了经验性的解决方案。我尽可能多地罗列问题并给出解决方法（同时给出错误的方法和正确的方法，以及好的方法和更好的方法，并进行分析和比较）和建议，并且尽量覆盖.NET 4.0中C#的新特性。我已经用Visual Studio 2010编写并调试和运行（在Release状态下）了书中所有的代码，我期望你也这样做。相信当你调试完书中所有的示例时，你会对.NET和C#有更深入的认识，同时你也会对自己的代码更加有自信：没错，这就是我想要的代码，它规范，并且优雅而稳定。
如何阅读本书
本书适合那些有一定C#基础，并希望在技术上得到大幅提升的程序员。
本书并没有讲述C#中的基础概念，而是将使用C#过程中可能遇到的疑问或障碍一一罗列，并给出了建议。书中的大多数建议实战性很强，要完全理解其中的奥妙，首先应该动手写一写示例程序，或许在调试程序的过程中就会得到启发。
本书的每一个章节都比较独立，下一章的阅读并不需要前面章节作为铺垫。本书更像一本工具书，根据知识点对各个建议进行了分类，方便随时查阅。
资源及勘误
通常情况下，一个问题的解决方案往往不止一种，你可能会不同意本书中的一些观点，甚至会强烈反对。 没有关系，你可以通过luminji@hotmail.com（E-mail）与我分享你的宝贵意见，同时也可以在http://www.cnblogs.com/luminji下载书中的源码。我也经常在那里发表博客。当然，你一定也会在书中找到一些错误，我已经在博客上放置了一篇勘误表，我会在第一时间公布这些勘误。
致谢
最后，我想说的是，写作是一项耗时的工程，它不但压缩了我的工作时间，也完全耗掉了我的午休时间。首先要感谢我的同事，因为我时常因为思考本书的内容而工作不在状态，或者总在饭桌上讨论书中的一些技术细节。他们不但没有抱怨，反而提出了很多好的意见，他们是：胡昌俊、于文广、肖昌、樊鑫、王文壮、来伟、粟志辉、赵中海、王领军，还有其他很多朋友不再一一列出。他们是如此优秀和宽容，能和他们一起工作是我莫大的荣幸。
在漫长的写作过程中，难免让我情绪波动，是机械工业出版社华章分社的杨福川先生和杨绣国女士给我一如既往的支持与鼓励。当我想要偷懒的时候，是你们的敦促让我对写作时刻保持着热情。同时还要强调一下，没有福川，本书不会出版。另外，没有白宇女士的编辑工作，本书的文字看上去不会像现在这样流畅。
还要感谢我的家人，尤其是我的父母和妻子胡忠华。在过去这段时间里，我总是一回到家就打开电脑。陪妻子散步的时间没有了，聊天少了，家务活儿也很少做了。妻子的宽容让我有了更多的时间去写作。难得的是，中文系毕业的你在写作方面给我提出了很多好的建议。你的第一标准是：“如果我都看不懂，你还写什么书。”没有你的支持，本书不会诞生。
陆敏技
2011年7月
计算机\程序设计
包含大量最佳实践、实用性强、经验性解决方案、编写高质量代码
这是一本关于C#编码最佳实践的集大成之作，也是一本能指导C#程序员编写出高质量代码的指点迷津之作。全书从C#语法、程序的架构和设计、编码规范和编程习惯3大方面为广大的C#程序员们总结出了157条极富借鉴意义的建议，这些建议都是在实践中被证明是解决C#编码中疑难问题的最佳实践。如果能掌握本书中的内容，不仅能加深对C#语言的理解和提升程序架构和设计方面的能力，而且还能规范我们的开发行为和习惯，让我们成为一名优秀的程序员，让我们能编写出更高质量的代码。
——51CTO（www.51cto.com）
作为一名程序员，没有人愿意留下一堆糟糕的代码。如果我们编写的代码运行速度慢、消耗的内存多，而且还时不时地抛出一些莫名其妙的错误，我们一定会十分疑惑：我们的代码到底怎么了？问题很明显：我们编写的代码质量不高。本书从C#语言本身、程序的架构和设计、编码规范和编程习惯等3大方面就如何编写高质量的C#代码给出了大量的宝贵建议。如果能理解并熟练使用本书中的知识，我们不仅能在一定程度上避免糟糕的代码，而且还能大幅度提升编码水平。
——马伟 资深微软技术专家/ASP.NET MVP/畅销书《ASP.NET 4权威指南》作者
学习任何一门编程语言，入门一般都不难，难的是进阶和提高；让程序跑起来不难，难的是如何让程序跑得又快又好。作为一个程序员，我们在进阶的路上总会遇到各种各样的问题，有时候需要为这些问题付出代价，需要在不断试错和纠错中积累经验。很幸运的是，本书针对C#语法、程序的架构和设计、编码规范和编程习惯等3大方面给出了157条宝贵的建议，每一条建议都来自于实践和经验的总结，每一条建议都能帮你避免在编码时可能会犯下的错误，实用性极强。强烈推荐！
——姜晓东 资深微软技术专家/畅销书《C# 4.0权威指南》作者
陆敏技 著：陆敏技 资深微软技术专家，从事软件开发工作近10年，精通于C#、WPF、WCF、ASP.NET和.NET技术，积累了丰富的开发经验，现任一大型IT公司技术总监。此外，他还非常擅长于分布式开发技术。
前 言
第一部分 语言篇
第1章 基本语言要素 / 2
建议1：正确操作字符串 / 2
建议2：使用默认转型方法 / 6
建议3：区别对待强制转型与as和is / 9
建议4：TryParse比Parse好 / 12
建议5：使用int 来确保值类型也可以为null / 15
建议6：区别readonly和const的使用方法 / 16
建议7：将0值作为枚举的默认值 / 19
建议8：避免给枚举类型的元素提供显式的值 / 20
建议9：习惯重载运算符 / 22
建议10：创建对象时需要考虑是否实现比较器 / 23
建议11：区别对待==和Equals / 27
建议12：重写Equals时也要重写GetHashCode / 29
建议13：为类型输出格式化字符串 / 32
建议14：正确实现浅拷贝和深拷贝 / 36
建议15：使用dynamic来简化反射实现 / 40
第2章 集合和LINQ / 43
建议16：元素数量可变的情况下不应使用数组 / 43
建议17：多数情况下使用foreach进行循环遍历 / 45
建议18：foreach不能代替for / 51
建议19：使用更有效的对象和集合初始化 / 53
建议20：使用泛型集合代替非泛型集合 / 54
建议21：选择正确的集合 / 57
建议22：确保集合的线程安全 / 61
建议23：避免将List
建议24：迭代器应该是只读的 / 67
建议25：谨慎集合属性的可写操作 / 68
建议26：使用匿名类型存储LINQ查询结果 / 70
建议27：在查询中使用Lambda表达式 / 73
建议28：理解延迟求值和主动求值之间的区别 / 75
建议29：区别LINQ查询中的IEnumerable
建议30：使用LINQ取代集合中的比较器和迭代器 / 80
建议31：在LINQ查询中避免不必要的迭代 / 83
第3章 泛型、委托和事件 / 86
建议32：总是优先考虑泛型 / 86
建议33：避免在泛型类型中声明静态成员 / 88
建议34：为泛型参数设定约束 / 90
建议35：使用default为泛型类型变量指定初始值 / 92
建议36：使用FCL中的委托声明 / 94
建议37：使用Lambda表达式代替方法和匿名方法 / 96
建议38：小心闭包中的陷阱 / 99
建议39：了解委托的实质 / 103
建议40：使用event关键字为委托施加保护 / 106
建议41：实现标准的事件模型 / 108
建议42：使用泛型参数兼容泛型接口的不可变性 / 109
建议43：让接口中的泛型参数支持协变 / 111
建议44：理解委托中的协变 / 112
建议45：为泛型类型参数指定逆变 / 114
第4章 资源管理和序列化 / 116
建议46：显式释放资源需继承接口IDisposable / 116
建议47：即使提供了显式释放方法，也应该在终结器中提供隐式清理 / 119
建议48：Dispose方法应允许被多次调用 / 120
建议49：在Dispose模式中应提取一个受保护的虚方法 / 121
建议50：在Dispose模式中应区别对待托管资源和非托管资源 / 123
建议51：具有可释放字段的类型或拥有本机资源的类型应该是可释放的 / 124
建议52：及时释放资源 / 125
建议53：必要时应将不再使用的对象引用赋值为null / 127
建议54：为无用字段标注不可序列化 / 131
建议55：利用定制特性减少可序列化的字段 / 136
建议56：使用继承ISerializable接口更灵活地控制序列化过程 / 137
建议57：实现ISerializable的子类型应负责父类的序列化 / 140
第5章 异常与自定义异常 / 144
建议58：用抛出异常代替返回错误代码 / 144
建议59：不要在不恰当的场合下引发异常 / 147
建议60：重新引发异常时使用Inner Exception / 150
建议61：避免在finally内撰写无效代码 / 151
建议62：避免嵌套异常 / 157
建议63：避免“吃掉”异常 / 160
建议64：为循环增加Tester-Doer模式而不是将try-catch置于循环内 / 161
建议65：总是处理未捕获的异常 / 162
建议66：正确捕获多线程中的异常 / 166
建议67：慎用自定义异常 / 168
建议68：从System.Exception或其他常见的基本异常中派生异常 / 170
建议69：应使用finally避免资源泄漏 / 172
建议70：避免在调用栈较低的位置记录异常 / 175
第6章 异步、多线程、任务和并行 / 177
建议71：区分异步和多线程应用场景 / 177
建议72：在线程同步中使用信号量 / 180
建议73：避免锁定不恰当的同步对象 / 184
建议74：警惕线程的IsBackground / 188
建议75：警惕线程不会立即启动 / 189
建议76：警惕线程的优先级 / 191
建议77：正确停止线程 / 193
建议78：应避免线程数量过多 / 194
建议79：使用ThreadPool或BackgroundWorker代替Thread / 196
建议80：用Task代替ThreadPool / 198
建议81：使用Parallel简化同步状态下Task的使用 / 202
建议82：Parallel简化但不等同于Task默认行为 / 204
建议83：小心Parallel中的陷阱 / 205
建议84：使用PLINQ / 208
建议85：Task中的异常处理 / 209
建议86：Parallel中的异常处理 / 214
建议87：区分WPF和WinForm的线程模型 / 216
建议88：并行并不总是速度更快 / 220
建议89：在并行方法体中谨慎使用锁 / 222
第二部分 架构篇
第7章 成员设计 / 226
建议90：不要为抽象类提供公开的构造方法 / 226
建议91：可见字段应该重构为属性 / 226
建议92：谨慎将数组或集合作为属性 / 227
建议93：构造方法应初始化主要属性和字段 / 228
建议94：区别对待override和new / 229
建议95：避免在构造方法中调用虚成员 / 235
建议96：成员应优先考虑公开基类型或接口 / 236
建议97：优先考虑将基类型或接口作为参数传递 / 237
建议98：用params减少重复参数 / 237
建议99：重写时不应使用子类参数 / 238
建议100：静态方法和实例方法没有区别 / 239
建议101：使用扩展方法，向现有类型“添加”方法 / 240
第8章 类型设计 / 243
建议102：区分接口和抽象类的应用场合 / 243
建议103：区分组合和继承的应用场合 / 245
建议104：用多态代替条件语句 / 248
建议105：使用私有构造函数强化单例 / 251
建议106：为静态类添加静态构造函数 / 253
建议107：区分静态类和单例 / 255
建议108：将类型标识为sealed / 255
建议109：谨慎使用嵌套类 / 256
建议110：用类来代替enum / 257
建议111：避免双向耦合 / 260
建议112：将现实世界中的对象抽象为类，将可复用对象圈起来就是命名空间 / 262
第9章 安全性设计 / 264
建议113：声明变量前考虑最大值 / 264
建议114：MD5不再安全 / 265
建议115：通过HASH来验证文件是否被篡改 / 268
建议116：避免用非对称算法加密文件 / 269
建议117：使用SSL确保通信中的数据安全 / 273
建议118：使用SecureString保存密钥等机密字符串 / 284
建议119：不要使用自己的加密算法 / 289
建议120：为程序集指定强名称 / 289
建议121：为应用程序设定运行权限 / 291
第三部分 编码规范及习惯
第10章 命名规范 / 296
建议122：以
建议123：程序集不必与命名空间同名 / 296
建议124：考虑在命名空间中使用复数 / 297
建议125：避免用FCL的类型名称命名自己的类型 / / 297
建议126：用名词和名词组给类型命名 / 298
建议127：用形容词组给接口命名 / 299
建议128：考虑让派生类的名字以基类名字作为后缀 / 300
建议129：泛型类型参数要以T作为前缀 / 300
建议130：以复数命名枚举类型，以单数命名枚举元素 / 301
建议131：用PascalCasing命名公开元素 / 302
建议132：考虑用类名作为属性名 / 302
建议133：用camelCasing命名私有字段和局部变量 / 303
建议134：有条件地使用前缀 / 304
建议135： 考虑使用肯定性的短语命名布尔属性 / 305
建议136：优先使用后缀表示已有类型的新版本 / 306
建议137：委托和事件类型应添加上级后缀 / 307
建议138：事件和委托变量使用动词或形容词短语命名 / 308
建议139：事件处理器命名采用组合方式 / 309
第11章 代码整洁 / 311
建议140：使用默认的访问修饰符 / 311
建议141：不知道该不该用大括号时，就用 / 312
建议142：总是提供有意义的命名 / 314
建议143：方法抽象级别应在同一层次 / 315
建议144：一个方法只做一件事 / 316
建议145：避免过长的方法和过长的类 / 317
建议146：只对外公布必要的操作 / 318
建议147：重构多个相关属性为一个类 / 319
建议148：不重复代码 / 320
建议149：使用表驱动法避免过长的if和switch分支 / 321
建议150：使用匿名方法、Lambda表达式代替方法 / 324
建议151：使用事件访问器替换公开的事件成员变量 / 325
建议152：最少，甚至是不要注释 / 326
建议153：若抛出异常，则必须要注释 / 326
第12章 规范开发行为 / 327
建议154：不要过度设计，在敏捷中体会重构的乐趣 / 327
建议155：随生产代码一起提交单元测试代码 / 336
建议156：利用特性为应用程序提供多个版本 / 342
建议157：从写第一个界面开始，就进行自动化测试 / 344
