Effective C#：改善C#代码的50个有效方法（原书第3版） - (EPUB全文下载)

文件大小：0.37 mb。
文件格式：epub 格式。
书籍内容：

Effective C#：改善C#代码的50个有效方法（原书第3版）
第1章 C#语言的编程习惯
第1条：优先使用隐式类型的局部变量
第2条：考虑用readonly代替const
第3条：优先考虑is或as运算符，尽量少用强制类型转换
第4条：用内插字符串取代string.Format（）
第5条：用FormattableString取代专门为特定区域而写的字符串
第6条：不要用表示符号名称的硬字符串来调用API
第7条：用委托表示回调
第8条：用null条件运算符调用事件处理程序
第9条：尽量避免装箱与取消装箱这两种操作
第10条：只有在应对新版基类与现有子类之间的冲突时才应该使用new修饰符
第2章 .NET的资源管理
第11条：理解并善用.NET的资源管理机制
第12条：声明字段时，尽量直接为其设定初始值
第13条：用适当的方式初始化类中的静态成员
第14条：尽量删减重复的初始化逻辑
第15条：不要创建无谓的对象
第16条：绝对不要在构造函数里面调用虚函数
第17条：实现标准的dispose模式
第3章 合理地运用泛型
第18条：只定义刚好够用的约束条件
第19条：通过运行期类型检查实现特定的泛型算法
第20条：通过IComparable<T>及IComparer<T>定义顺序关系
第21条：创建泛型类时，总是应该给实现了IDisposable的类型参数提供支持
第22条：考虑支持泛型协变与逆变
第23条：用委托要求类型参数必须提供某种方法
第24条：如果有泛型方法，就不要再创建针对基类或接口的重载版本
第25条：如果不需要把类型参数所表示的对象设为实例字段，那么应该优先考虑创建泛型方法，而不是泛型类
第26条：实现泛型接口的同时，还应该实现非泛型接口
第27条：只把必备的契约定义在接口中，把其他功能留给扩展方法去实现
第28条：考虑通过扩展方法增强已构造类型的功能
第4章 合理地运用LINQ
第29条：优先考虑提供迭代器方法，而不要返回集合
第30条：优先考虑通过查询语句来编写代码，而不要使用循环语句
第31条：把针对序列的API设计得更加易于拼接
第32条：将迭代逻辑与操作、谓词及函数解耦
第33条：等真正用到序列中的元素时再去生成
第34条：考虑通过函数参数来放松耦合关系
第35条：绝对不要重载扩展方法
第36条：理解查询表达式与方法调用之间的映射关系
第37条：尽量采用惰性求值的方式来查询，而不要及早求值
第38条：考虑用lambda表达式来代替方法
第39条：不要在Func与Action中抛出异常
第40条：掌握尽早执行与延迟执行之间的区别
第41条：不要把开销较大的资源捕获到闭包中
第42条：注意IEnumerable与IQueryable形式的数据源之间的区别
第43条：用Single（）及First（）来明确地验证你对查询结果所做的假设
第44条：不要修改绑定变量
第5章 合理地运用异常
第45条：考虑在方法约定遭到违背时抛出异常
第46条：利用using与try/finally来清理资源
第47条：专门针对应用程序创建异常
第48条：优先考虑做出强异常保证
第49条：考虑用异常筛选器来改写先捕获异常再重新抛出的逻辑
第50条：合理利用异常筛选器的副作用来实现某些效果
中英文词汇对照表
第1章　C#语言的编程习惯
能用的东西为什么要改？因为改了之后效果更好。开发者换用其他工具或语言来编程也是这个道理，因为换了之后工作效率更高。如果不肯改变现有的习惯，那么就体会不到新技术的好处，但如果这种新的技术与你熟悉的技术看上去很像，那么改起来就特别困难。例如C#语言就与C++或Java语言相似，由于它们都用一对花括号来表示代码块，因此，开发者即便切换到了C#语言，也总是会把使用那两门语言时所养成的习惯直接带过来，这样做其实并不能发挥出C#的优势。这门语言的首个商用版本发布于2001年，经过这些年的演变，当前这一版C#语言与C++或Java之间的差别已经远远大于那个年代。如果你是从其他语言转入C#的，那么需要学习C#语言自己的编程习惯，使得这门语言能够促进你的工作，而不是阻碍你的工作。本章会提醒大家把那些与C#编程风格不符的做法改掉，并培养正确的编程习惯。
第1条：优先使用隐式类型的局部变量
隐式类型的局部变量是为了支持匿名类型机制而加入C#语言的。之所以要添加这种机制，还有一个原因在于：某些查询操作所获得的结果是IQueryable，而其他一些则返回IEnumerable。如果硬要把前者当成后者来对待，那就无法使用由IQueryProvider所提供的很多增强功能了（参见第42条）。用var来声明变量而不指明其类型，可以令开发者把注意力更多地集中在名称上面，从而更好地了解其含义。例如，jobsQueuedByRegion这个变量名本身就已经把该变量的用途说清楚了，即便将它的类型Dictionary>写出来，也不会给人提供多少帮助。
对于很多局部变量，笔者都喜欢用var来声明，因为这可以令人把注意力放在最为重要的部分，也就是变量的语义上面，而不用分心去考虑其类型。如果代码使用了不合适的类型，那么编译器会提醒你，而不用你提前去操心。变量的类型安全与开发者有没有把变量的类型写出来并不是同一回事。在很多场合，即便你费心去区分IQueryable与IEnumerable之间的差别，开发者也无法由此获得有用的信息。如果你非要把类型明确地告诉编译器，那么有时可能会改变代码的执行方式（参见第42条）。在很多情况下，完全可以使用var来声明隐式类型的局部变量，因为编译器会自动选择合适的类型。但是不能滥用这种方式，因为那样会令代码难于阅读，甚至可能产生微妙的类型转换bug。
局部变量的类型推断机制并不影响C#的静态类型检查。这是为什么呢？首先必须了解局部变量的类型推断不等于动态类型检查。用var来声明的变量不是动态变量，它的类型会根据赋值符号右侧 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。