logo
分类于: 编程语言 计算机基础

简介

编写高质量代码:改善C#程序的157个建议

编写高质量代码:改善C#程序的157个建议 7.1分

资源最后更新于 2020-03-29 04:31:49

作者:陆敏技

出版社:出版社机械工业出版社

出版日期:2011-10

ISBN:9787111356493

文件格式: pdf

标签: 编程 软件开发 代码

简介· · · · · ·

本书是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

想要: 点击会收藏到你的 我的收藏,可以在这里查看

已收: 表示已经收藏

Tips: 注册一个用户 可以通过用户中心得到电子书更新的通知哦

目录

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