这篇文章，将《Effective C# Second Edition》一书中适用于Unity游戏引擎里使用C#的经验之谈进行了提炼，总结成为21条（一开始总结的是22条，后来发现第22条也是.NET的特性，Unity版本的mono并没有实现，所以严格意义上来说是21条）准则，供各位快速地掌握这本书的知识梗概，在Unity中写出更高质量的C#代码。
《Effective C# Second Edition》一书原本有50条原则，但这50条原则是针对C#语言本身以及.NET来写的，我在阅读过程中，发现是有些原则并不适用于Unity中mono版本的C#的使用。于是，在进行读书笔记总结的时候，将不适用的原则略去，同时将适用的原则进行提炼，总结出21条，构成本文的内容。
需要注意，因为是挑出了书中适用的准则，导致准则序号有些跳跃，为了阅读方便，本文对这些序号进行了重新排列。重排后，标题中与书中序号不一样的准则，都在该原则总结的末尾注明了对应的原书序号。
同样地，作为总结式文章，每一条的内容都高度概括，也许理解坡度比较陡，若有读到不太理解的地方，建议大家去阅读原书，英文版和中文版均可，看看原书中提供的各种代码与示例，这样掌握起来就会事半功倍。
本文内容思维导图式总结
以下是本文内容，提高Unity中C#代码质量的22条准则的总结式思维导图：
原则1
尽可能地使用属性而不是可直接访问的数据成员
● 属性(property)一直是C#语言中比较有特点的存在。属性允许将数据成员作为共有接口的一部分暴露出去，同时仍旧提供面向对象环境下所需的封装。属性这个语言元素可以让你像访问数据成员一样使用，但其底层依旧是使用方法实现的。
● 使用属性，可以非常轻松的在get和set代码段中加入检查机制。
需要注意，正因为属性是用方法实现的，所以它拥有方法所拥有的一切语言特性：
1）属性增加多线程的支持是非常方便的。你可以加强 get 和 set 访问器（accessors）的实现来提供数据访问的同步。
2）属性可以被定义为virtual。
3）可以把属性扩展为abstract。
4）可以使用泛型版本的属性类型。
5）属性也可以定义为接口。
6）因为实现实现访问的方法get与set是独立的两个方法，在C# 2.0之后，你可以给它们定义不同的访问权限，来更好的控制类成员的可见性。
7）而为了和多维数组保持一致，我们可以创建多维索引器，在不同的维度上使用相同或不同类型。
无论何时，需要在类型的公有或保护接口中暴露数据，都应该使用属性。如果可以也应该使用索引器来暴露序列或字典。现在多投入一点时间使用属性，换来的是今后维护时的更加游刃有余。
原则2
偏向于使用运行时常量而不是编译时常量
对于常量，C#里有两个不同的版本：运行时常量（readonly）和编译时常量（const）。
应该尽量使用运行时常量，而不是编译器常量。虽然编译器常量略快，但并没有运行时常量那么灵活。应仅仅在那些性能异常敏感，且常量的值在各个版本之间绝对不会变化时，再使用编译时常量。
编译时常量与运行时常量不同之处表现在于他们的访问方式不同，因为Readonly值是运行时解析的：
● 编译时常量（const）的值会被目标代码中的值直接取代。
● 运行时常量（readonly）的值是在运行时进行求值。● 引用运行时生成的IL将引用到readonly变量，而不是变量的值。
这个差别就带来了如下规则：
● 编译时常量（const）仅能用于数值和字符串。
● 运行时常量（readonly）可以为任意类型。运行时常量必须在构造函数或初始化器中初始化，因为在构造函数执行后不能再被修改。你可以让某个readonly值为一个DataTime结构，而不能指定某个const为DataTIme。
● 可以用readonly值保存实例常量，为类的每个实例存放不同的值。而编译时常量就是静态的常量。
● 有时候你需要让某个值在编译时才确定，就最好是使用运行时常量（readonly）。
● 标记版本号的值就应该使用运行时常量，因为它的值会随着每个不同版本的发布而改变。
● const优于readonly的地方仅仅是性能，使用已知的常量值要比访问readonly值略高一点，不过这其中的效率提升，可以说是微乎其微的。
综上，在编译器必须得到确定数值时，一定要使用const。例如特性（attribute）的参数和枚举的定义，还有那些在各个版本发布之间不会变化的值。除此之外的所有情况，都应尽量选择更加灵活的readonly常量。
最低0.47元/天 解锁文章
2406
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
