这本书《编写高质量代码改善c#程序的157个建议》是一本很有用的编程指南，主要针对C#程序员如何写出更高质量的代码。全书分为三个部分：语言篇、架构篇和编码规范及习惯，涵盖了很多细节知识点。
在语言篇里，作者详细讲解了C#语法相关的知识，比如字符串操作、集合、LINQ、泛型、委托等核心内容，并给出了一些实用的建议。比如，在处理枚举类型时，建议将0值作为默认值，避免显式指定元素值；在异常处理中，强调要正确使用try-catch而不是随便抛出错误代码。
架构篇主要讲程序的设计和架构，涉及成员设计、面向对象类型设计以及安全性设计。这部分内容对于构建稳健的系统非常重要，比如如何合理使用静态类和单例模式，如何避免双向耦合等。
第三部分是关于编码规范和习惯的培养，包括命名规范、代码整洁度以及开发行为规范。这部分建议非常实用，比如强调方法要单一职责、避免冗长的if-else分支、尽量减少注释等等。
整体来看，这本书的内容非常全面，每个建议都结合了正反两方面的案例进行分析，帮助程序员更好地理解和掌握高质量编程的原则。我觉得这些技巧对提升代码质量和开发效率都有很大帮助，尤其是对于刚开始学习C#的新手来说，这本书绝对是一本很好的参考书。
编写高质量代码改善c#程序的157个建议是一本关于如何编写高质量C#代码的工具书，由陆敏技编著。本书从语法、程序架构和设计，编码习惯和编程规范3个层面深入探讨，编写高质理c#代码的技巧、禁忌和最佳实践，为C#程序员如何编写更高质量的C#代码提供了157条极为宝贵的建议。对于每一个问题，不仅以建议的方式给出了被实践证明为十分优秀的解决方案，而且还给出了经常被误用或被错误理解的不好的解决方案，从正反两个方面进行了分析和对比，能够有效帮助程序员形成良好的编程习惯。
全书简介
《编写高质量代码改善c#程序的157个建议》全书一共三个部分，第一部分专注于C#语言本身，一共89条建议，涵盖了C#语言基本要素、集合、LINQ、泛型、委托、事件、资源管理、序列化、异常处理、异步、多线程、任务和并行编程等与C#语法相关的核心内容；第二部分重点讲解了C#程序的设计和架构，一共32条建议，涉及成员设计、面向对象的类型设计、安全性设计等重要方面的内容；第三部分探讨了C#的编码规范及编程习惯，一共36条建议，包含C#命名规范、如何使代码更整洁以及如何规范开发行为等方面的内容。
编写高质量代码改善c#程序的157个建议pdf章节目录
前言
第一部分 语言篇
第1章 基本语言要素
建议1：正确操作字符串
建议2：使用默认转型方法
建议3：区别对待强制转型与as和is
建议4：TryParse比Parse好
建议5：使用int来确保值类型也可以为null
建议6：区别readonly和const的使用方法
建议7：将0值作为枚举的默认值
建议8：避免给枚举类型的元素提供显式的值
建议9：习惯重载运算符
建议10：创建对象时需要考虑是否实现比较器
建议11：区别对待==和Equals
建议12：重写Equals时也要重写GetHashCode
建议13：为类型输出格式化字符串
建议14：正确实现浅拷贝和深拷贝
建议15：使用dynamic来简化反射实现
第2章 集合和LINQ
建议16：元素数量可变的情况下不应使用数组
建议17：多数情况下使用foreach进行循环遍历
建议18：foreach不能代替for
建议19：使用更有效的对象和集合初始化
建议20：使用泛型集合代替非泛型集合
建议21：选择正确的集合
建议22：确保集合的线程安全
建议23：避免将List〈T〉作为自定义集合类的基类
建议24：迭代器应该是只读的
建议25：谨慎集合属性的可写操作
建议26：使用匿名类型存储LINQ查询结果
建议27：在查询中使用Lambda表达式
建议28：理解延迟求值和主动求值之间的区别
建议29：区别LINQ查询中的IEnumerable〈T〉和IQueryable〈T〉
建议30：使用LINQ取代集合中的比较器和迭代器
建议31：在LINQ查询中避免不必要的迭代
第3章 泛型、委托和事件
建议32：总是优先考虑泛型
建议33：避免在泛型类型中声明静态成员
建议34：为泛型参数设定约束
建议35：使用default为泛型类型变量指定初始值
建议36：使用FCL中的委托声明
建议37：使用Lambda表达式代替方法和匿名方法
建议38：小心闭包中的陷阱
建议39：了解委托的实质
建议40：使用event关键字为委托施加保护
建议41：实现标准的事件模型
建议42：使用泛型参数兼容泛型接口的不可变性
建议43：让接口中的泛型参数支持协变
建议44：理解委托中的协变
建议45：为泛型类型参数指定逆变
第4章 资源管理和序列化
建议46：显式释放资源需继承接口IDisposable
建议47：即使提供了显式释放方法，也应该在终结器中提供隐式清理
建议48：Dispose方法应允许被多次调用
建议49：在Dispose模式中应提取一个受保护的虚方法
建议50：在Dispose模式中应区别对待托管资源和非托管资源
建议51：具有可释放字段的类型或拥有本机资源的类型应该是可释放的
建议52：及时释放资源
建议53：必要时应将不再使用的对象引用赋值为null
建议54：为无用字段标注不可序列化
建议55：利用定制特性减少可序列化的字段
建议56：使用继承ISerializable接口更灵活地控制序列化过程
建议57：实现ISerializable的子类型应负责父类的序列化
第5章 异常与自定义异常
建议58：用抛出异常代替返回错误代码
建议59：不要在不恰当的场合下引发异常
建议60：重新引发异常时使用Inner Exception
建议61：避免在finally内撰写无效代码
建议62：避免嵌套异常
建议63：避免“吃掉”异常
建议64：为循环增加Tester-Doer模式而不是将try-catch置于循环内
建议65：总是处理未捕获的异常
建议66：正确捕获多线程中的异常
建议67：慎用自定义异常
建议68：从System.Exception或其他常见的基本异常中派生异常
建议69：应使用finally避免资源泄漏
建议70：避免在调用栈较低的位置记录异常
第6章 异步、多线程、任务和并行
建议71：区分异步和多线程应用场景
建议72：在线程同步中使用信号量
建议73：避免锁定不恰当的同步对象
建议74：警惕线程的IsBackground
建议75：警惕线程不会立即启动
建议76：警惕线程的优先级
建议77：正确停止线程
建议78：应避免线程数量过多
建议79：使用ThreadPool或BackgroundWorker代替Thread
建议80：用Task代替ThreadPool
建议81：使用Parallel简化同步状态下Task的使用
建议82：Parallel简化但不等同于Task默认行为
建议83：小心Parallel中的陷阱
建议84：使用PLINQ
建议85：Task中的异常处理
建议86：Parallel中的异常处理
建议87：区分WPF和WinForm的线程模型
建议88：并行并不总是速度更快
建议89：在并行方法体中谨慎使用锁
第二部分 架构篇
第7章 成员设计
建议90：不要为抽象类提供公开的构造方法
建议91：可见字段应该重构为属性
建议92：谨慎将数组或集合作为属性
建议93：构造方法应初始化主要属性和字段
建议94：区别对待override和new
建议95：避免在构造方法中调用虚成员
建议96：成员应优先考虑公开基类型或接口
建议97：优先考虑将基类型或接口作为参数传递
建议98：用params减少重复参数
建议99：重写时不应使用子类参数
建议100：静态方法和实例方法没有区别
建议101：使用扩展方法，向现有类型“添加”方法
第8章 类型设计
建议102：区分接口和抽象类的应用场合
建议103：区分组合和继承的应用场合
建议104：用多态代替条件语句
建议105：使用私有构造函数强化单例
建议106：为静态类添加静态构造函数
建议107：区分静态类和单例
建议108：将类型标识为sealed
建议109：谨慎使用嵌套类
建议110：用类来代替enum
建议111：避免双向耦合
建议112：将现实世界中的对象抽象为类，将可复用对象圈起来就是命名空间
第9章 安全性设计
建议113：声明变量前考虑最大值
建议114：MD5不再安全
建议115：通过HASH来验证文件是否被篡改
建议116：避免用非对称算法加密文件
建议117：使用SSL确保通信中的数据安全
建议118：使用SecureString保存密钥等机密字符串
建议119：不要使用自己的加密算法
建议120：为程序集指定强名称
建议121：为应用程序设定运行权限
第三部分 编码规范及习惯
第10章 命名规范
建议122：以〈Company〉.〈Component〉为命名空间命名
建议123：程序集不必与命名空间同名
建议124：考虑在命名空间中使用复数
建议125：避免用FCL的类型名称命名自己的类型
建议126：用名词和名词组给类型命名
建议127：用形容词组给接口命名
建议128：考虑让派生类的名字以基类名字作为后缀
建议129：泛型类型参数要以工作为前缀
建议130：以复数命名枚举类型，以单数命名枚举元素
建议131：用PascalCasing命名公开元素
建议132：考虑用类名作为属性名
建议133：用camelCasing命名私有字段和局部变量
建议134：有条件地使用前缀
建议135： 考虑使用肯定性的短语命名布尔属性
建议136：优先使用后缀表示已有类型的新版本
建议137：委托和事件类型应添加上级后缀
建议138：事件和委托变量使用动词或形容词短语命名
建议139：事件处理器命名采用组合方式
第11章 代码整洁
建议140：使用默认的访问修饰符
建议141：不知道该不该用大括号时，就用
建议142：总是提供有意义的命名
建议143：方法抽象级别应在同一层次
建议144：一个方法只做一件事
建议145：避免过长的方法和过长的类
建议146：只对外公布必要的操作
建议147：重构多个相关属性为一个类
建议148：不重复代码
建议149：使用表驱动法避免过长的if和switch分支
建议150：使用匿名方法、Lambda表达式代替方法
建议151：使用事件访问器替换公开的事件成员变量
建议152：最少，甚至是不要注释
建议153：若抛出异常，则必须要注释
第12章 规范开发行为
建议154：不要过度设计，在敏捷中体会重构的乐趣
建议155：随生产代码一起提交单元测试代码
建议156：利用特性为应用程序提供多个版本
建议157：从写第一个界面开始，就进行自动化测试
使用说明
1、下载并解压，得出pdf文件
2、如果打不开本文件，请务必下载pdf阅读器
3、安装后，在打开解压得出的pdf文件
4、双击进行阅读
共有 0条评论