首 页
手机版

编写高质量代码改善c#程序的157个建议 陆敏技pdf扫描版

  • 软件大小:6.67M
  • 软件语言:简体中文
  • 软件类型:国产软件
  • 软件授权:免费软件
  • 更新时间:2023/08/31
  • 软件类别:电子阅读
  • 应用平台:Windows11,Windows10,Windows8,Windows7,WinVista,Win2003,WinXP,Win2000
网友评分:8.0分
网友评论 下载地址 收藏该页
本地下载

编写高质量代码改善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、双击进行阅读

收起介绍展开介绍
  • 下载地址
编写高质量代码改善c#程序的157个建议 陆敏技pdf扫描版

有问题? 点此报错

发表评论

0条评论