具体描述
本书是C#程序员进阶修炼的必读之作，包含的全部都是C#编码的最佳实践，从语言本身、程序的设计和架构、编码规范和编程习惯等三大方面对C#程序员遇到的经典问题给出了经验性的解决方案，为C#程序员如何编写更高质量的C#代码提供了157条极为宝贵的建议。对于每一个问题，不仅以建议的方式给出了被实践证明为十分优秀的解决方案，而且还给出了经常被误用或被错误理解的不好的解决方案，从正反两个方面进行了分析和对比。
全书一共三个部分，第一部分专注于C#语言本身，一共89条建议，涵盖了C#语言基本要素、集合、LINQ、泛型、委托、事件、资源管理、序列化、异常处理、异步、多线程、任务和并行编程等与C#语法相关的核心内容；第二部分重点讲解了C#程序的设计和架构，一共32条建议，涉及成员设计、面向对象的类型设计、安全性设计等重要方面的内容；第三部分探讨了C#的编码规范及编程习惯，一共36条建议，包含C#命名规范、如何使代码更整洁以及如何规范开发行为等方面的内容。
本书是一本关于如何编写高质量C#代码的工具书，列举的问题非常典型，给出的建议也非常实用，其中的每一条建议都有可能在我们编写下一行代码的时候被用到。你可以将此书搁置在案头，以便有需要的时候随时查阅。
作者简介
陆敏技，资深软件工程师、项目经理和架构师，从事软件开发工作近10年。尤其精通微软技术，对C#、WPF、WCF、ASP.NET和.NET技术有十分深入的研究，曾参与和主导了大量的相关项目的架构和开发工作，积累了丰富的经验。此外，他还非常擅长于分布式开发技术，而且有丰富的培训和授课经验。活跃于博客园等技术社区，乐于分享，有较高的知名度和社区影响力。作者博客地址：http://www.cnblogs.com/luminji
目录信息
第一部分 语言篇
第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<T>作为自定义集合类的基类 / 64
建议24：迭代器应该是只读的 / 67
建议25：谨慎集合属性的可写操作 / 68
建议26：使用匿名类型存储LINQ查询结果 / 70
建议27：在查询中使用Lambda表达式 / 73
建议28：理解延迟求值和主动求值之间的区别 / 75
建议29：区别LINQ查询中的IEnumerable<T>和IQueryable<T> / 78
建议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：以<Company>.<Component>为命名空间命名 / 296
建议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
· · · · · · (收起)
读后感
整体还不错，涉及的知识点也比较全面（.net 4.0以前的），但有些知识点，是可以讲的详细一点的，但书中讲的稍简单了点，例子较少，比如，对Task的讲解应该是可以多一些例子的~ 毕竟Task在平常的开发中也是一个非常重要的功能！
评分整体还不错，涉及的知识点也比较全面（.net 4.0以前的），但有些知识点，是可以讲的详细一点的，但书中讲的稍简单了点，例子较少，比如，对Task的讲解应该是可以多一些例子的~ 毕竟Task在平常的开发中也是一个非常重要的功能！
评分整体还不错，涉及的知识点也比较全面（.net 4.0以前的），但有些知识点，是可以讲的详细一点的，但书中讲的稍简单了点，例子较少，比如，对Task的讲解应该是可以多一些例子的~ 毕竟Task在平常的开发中也是一个非常重要的功能！
评分整体还不错，涉及的知识点也比较全面（.net 4.0以前的），但有些知识点，是可以讲的详细一点的，但书中讲的稍简单了点，例子较少，比如，对Task的讲解应该是可以多一些例子的~ 毕竟Task在平常的开发中也是一个非常重要的功能！
评分整体还不错，涉及的知识点也比较全面（.net 4.0以前的），但有些知识点，是可以讲的详细一点的，但书中讲的稍简单了点，例子较少，比如，对Task的讲解应该是可以多一些例子的~ 毕竟Task在平常的开发中也是一个非常重要的功能！
用户评价
我曾经是一名“代码实现者”，只关注如何让程序按照我的意愿运行，却对代码的“内在美”知之甚少。直到接触了《编写高质量代码》，我才真正理解了“高质量”的含义。这本书没有讲太多高深的理论，而是通过大量生动、具体的例子，让我明白了代码的“生命力”在于它的可读性、可维护性和可扩展性。我以前写代码，就像是给自己留下“炸弹”，每次修改都是一次冒险，生怕牵一发动全身，把其他地方弄坏。读了这本书，我才恍然大悟，原来很多问题都可以避免，关键在于如何从一开始就构建一个“健康”的代码结构。书中关于“命名规范”、“函数设计”、“错误处理”等方面的讲解，看似基础，却蕴含着深刻的智慧。我开始反思自己过去的一些“偷懒”行为，例如随意命名变量、写过长的函数、忽视异常处理等等，这些行为不仅增加了我的开发负担，也给团队协作带来了巨大的困扰。这本书，让我从一个只追求“结果”的开发者，变成了一个更注重“过程”和“品质”的工程师。它不仅仅是一本书，更是一种编程哲学的启蒙。
评分这本书简直把我从一个“能跑就行”的开发者，变成了一个追求极致的代码美学追求者。我一直以为，代码写出来能运行，能实现功能就是胜利，直到我读了《编写高质量代码》。我以前写代码，就像是在工地里搬砖，一块一块地堆砌，堆得越高越好，从来没想过砖块的质地、垒砌的顺序、甚至是缝隙的填充方式，都会影响到整个建筑的稳固性和美观度。这本书就像一个经验丰富的建筑大师，他不会直接告诉你如何盖一座摩天大楼，而是从最基础的砖石结构、力学原理讲起，让你明白为什么某种材料比另一种更耐用，为什么特定的角度能承受更大的压力。我开始审视自己以前写的那些“能跑就行”的代码，简直不堪入目。变量名随意，函数动辄几百行，注释更是稀缺品，甚至有时候自己都看不懂自己写的东西。读了这本书，我才明白，代码的可读性、可维护性、可扩展性，和代码的功能实现一样重要，甚至在长远的开发过程中，它们的重要性会远远超过功能本身。现在，我会在动笔写代码之前，花更多时间去思考设计模式，去权衡不同的实现方案，去考虑未来的需求变化。我的代码，虽然可能在完成同样的功能上花费的时间稍长，但它变得更加清晰、有条理，就像一件精心雕琢的艺术品，而不是一堆杂乱无章的废料。这本书，真的让我对“写代码”这件事，有了全新的、更深刻的理解。
评分我一直认为编程是一门技术活，更是一种艺术。然而，多年实践下来，我发现自己似乎陷入了一个怪圈：我能快速地实现功能，但代码却像一团乱麻，每次维护都让我头疼不已，更不用说和团队成员协作了。直到我偶然翻阅了《编写高质量代码》，我才意识到，我之前所谓的“快速实现”，很多时候是以牺牲代码的健壮性和可维护性为代价的。这本书就像一盏明灯，照亮了我之前从未关注过的角落。它没有罗列枯燥的算法和数据结构，而是从更宏观的角度，深入浅出地讲解了代码设计的原则和实践。我明白了“低耦合、高内聚”的真正含义，理解了为什么函数应该尽可能短小精悍，为什么异常处理需要细致入微。书中提出的各种代码重构技巧，更是让我眼前一亮，我终于知道如何将那些“意大利面条式”的代码，逐步剥离，变得清晰有序。我开始尝试运用书中的理念，去改进我现有的项目，虽然过程有些痛苦，因为要推翻自己之前的许多“习惯”，但当看到代码的可读性和可维护性得到显著提升时，那种成就感是无法言喻的。这本书不仅仅是关于“如何写代码”，更是关于“如何优雅地写代码”，如何让你的代码能够经受住时间的考验，成为团队宝贵的财富。
评分作为一个在编程领域摸爬滚打多年的“老兵”，我一直以为自己对代码的理解已经相当到位了，各种设计模式、各种框架更是信手拈来。然而，《编写高质量代码》这本书，却给了我一个响亮的耳光。它以一种极其朴实却又直击要害的方式，揭示了我代码中那些隐藏的“缺陷”。我以前总觉得，只要功能实现了，逻辑清晰了，就是好代码，但忽略了代码的可读性、可维护性和可测试性这些“隐性”的优点。这本书就像一面镜子，让我看到了自己代码中那些“粗糙”的痕迹：冗余的设计、过度的耦合、模糊的命名…… 这些问题在小项目中可能不显眼，但一旦项目规模扩大，或者需要团队协作时，就会成为巨大的障碍。我尤其欣赏书中关于“代码的艺术”的探讨，它将编程提升到了一个更高的层面，让我意识到，编写高质量代码，不仅仅是技术活，更是一种严谨的态度和对卓越的追求。通过学习书中的方法，我开始有意识地审视自己的代码，并且积极地去实践那些更具鲁棒性和可维护性的编码风格。这本书，让我从一个“能写代码的人”变成了一个“懂得写好代码的人”。
评分坦白说，我当初拿到《编写高质量代码》这本书，主要是被它的书名所吸引，想着或许能学到一些炫酷的编程技巧，让我的代码看起来更“专业”。然而，这本书的内容远比我想象的要深刻得多，它并没有直接给出“怎么写”的答案，而是更侧重于“为什么这么写”以及“如何思考”。我以前写代码，更多的是一种“工程师思维”，追求的是功能的实现和效率的提升，但往往忽略了代码在整个生命周期中的其他维度。这本书就像一位经验丰富的导师，它引导我从一个“写代码的人”转变为一个“构建软件的人”。它让我理解了，一个“高质量的代码”，不仅仅是运行得快，更是易于理解、易于修改、易于测试，并且能够适应未来不断变化的需求。我尤其喜欢书中关于“代码的味道”的论述，第一次让我意识到，代码本身也具有某种“气质”，而这种气质直接影响着它给阅读者带来的感受。通过学习书中的案例分析，我开始学会识别那些“坏味道”的代码，并且找到了系统性地改进它们的方法。这本书对我最大的影响，在于它改变了我对编程的认知，让我明白，写出高质量的代码，是一项需要持续学习和实践的艺术，而不是一蹴而就的技能。
评分1.本书给出的建议都只属于理论级别的建议，而且大多建议还都是从clr，深入理解C#中照搬而来 2.本书很多建议都直接给出代码，并没有对代码有讲解，如果功力不强很难阅读 3.别浪费时间、金钱读这样一本书，真的。给3星的我都觉得是托。
评分对多线程、LINQ解释详细
评分对多线程、LINQ解释详细
评分还行
评分对多线程、LINQ解释详细
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有