1.2 - C#语言习惯 - 用运行时常量readonly而不是编译期常量const

　　C#中有两种类型的常量：编译期常量和运行时常量。二者有着截然不同的行为，使用不当将会带来性能上或正确性上的问题。

　　这两个问题最好都不要发生，不过若难以同时避免的话，那么一个略微慢一些但能保证正确的程序则要好过一个快速但不能正常工作的程序。

　　考虑到这些，你应该尽量使用运行时常量，而不是编译期常量。

　　虽然编译期常量略微快一些，但是却没有运行时常量那么灵活。应紧紧在那些性能异常敏感，且常量的值在各个版本之间绝对不会变化时，再使用编译期常量。

　　运行时常量使用readonly关键字声明，编译期常量则使用const关键字声明：

 // Compile time constant
 public const string Name = "张董";

 // Runtime constant
 ;

　　上述代码在类或struct的范围内演示了两种常量。编译期常量也可声明在方法中，而只读的运行时常量却不能声明在方法中。

　　编译期常量与运行时常量行为的不同之处在于对他们的访问方式不同。编译期常量的值是在目标代码中进行替换的。

　　下列代码：

 if (user.Age == Age)

　　将与如下代码编译成同样的IL（中间语言）：

 )

　　运行时常量将在运行时求职。引用运行时常量生成的IL将引用到readonly的变量，而不是变量的值。

　　这个差别会带来几个限制，会影响到选用哪种类型的常量。

　　编译期常量仅能用于基本类型（内建的整数和浮点类型）、枚举或字符串。只有这些类型才允许我们在初始化器中指定有意义的常量值。

　　在代码编译后得到的IL代码中，只有这些常量可直接被替换为它们的字面值。

　　例如，下面的代码就不会通过编译。

　　即使要初始化的常量类型属于值类型，也无法在C#中使用new操作符来初始化编译期常量：

// Does not compile, use readonly instead
, , , , , );

　　编译期常量const仅能用于数字和字符串。运行时常量readonly也是一种常量，因为在构造函数执行后未能被再次修改。

　　二者的区别在于，只读的值将在运行时给出，这自然会带来更好的灵活性。

　　例如，运行时常量可以为任意类型。运行时常量必须在构造函数或初始化器中初始化。

　　你可以让某个readonly值为一个DateTime结构，而不是指定某个const为DateTime。

　　你可以用readonly值保存实例常量，为类的每个实例存放不同的值。而编译期常量就是静态的常量。

　　二者最重要的区别在于，readonly值是在运行时解析的。引用一个readonly常量时声称的IL引用的是readonly变量，而不是其值。

　　这一点就会对日后的维护产生深远的影响。

　　编译期常量将生成同样的IL，就像直接在代码中给出数字一样，即使是跨程序集也是如此，即使另一个程序集中引用了某个程序集中的某个常量，相应常量也会被直接替换成这个值。

　　编译期常量与运行时常量的求值方式将会影响运行的兼容性。

　　假设我们在一个名为Infrastructure的程序集中分别定义了一个const字段和一个readonly字段：

 public class UsefulValues
 {
     ;
     ;
 }

　　在另一个程序集中，我们使用了这两个值：

 for(int i=UsefulValues.StartValue; i<UsefulValues.EndValue; i++)
 {
     Console.WriteLine("value is {0}", i);
 }

　　执行该程序，输出结果如下：

value
value
...
value 

　　过了一段时间，我们更新了Infrastructure程序集，做出了如下修改：

 public class UsefulValues
 {
     ;
     ;
 }

　　随后，在分发Infrastructure程序集时，并没有重新编译整个应用程序的所有程序集，我们期待的是如下的输出：

value
value
...
value 

　　但实际上，你却看不到任何输出。因为现在那个循环语句将使用105作为他的起始值，使用10作为他的结束条件。

　　C#编译器在第一次编译Application程序集时，将其中的EndValue替换成了它对应的常量值10.

　　而对于StartValue来说，因为它被声明为readonly，所以对其求值会发生在运行时。

　　因此，Application程序集在没有被重新编译的情况下，只要简单地更新一个Infrastructure程序集就够了。

　　相反，更改一个工友的编译期常量的值应该被看做是对类型接口的修改，你必须重新编译所有引用该常量的代码。

　　而更改只读常量的值缺紧紧算作是对类型实现的修改，它与其客户代码在二进制层次上是兼容的。

　　不过，有时你确实需要让某个值在编译时确定。

　　例如，考虑用一系列常量来标出对象的不同版本的序列化形式，其中这一组常量用来区分不同版本的对象。

　　这时，用来标记特定版本号的值就应该采用编译期常量，因为他们永远都不会改变。

　　而标记版本号的值就应该采用运行时常量，因为它的值会随着每个不同版本的发布而变化。

 private const int Version1_0 = 0x0100;
 private const int Version1_1 = 0x0101;
 private const int Version1_2 = 0x0102;
 // major release
 private const int Version2_0 = 0x0200;

 // check for the current version
 private static readonly int CurrentVersion = Version2_0;

　　使用运行时常量在每个存盘文件中保存当前的版本：

 // Read from persistent storage, check stored version against compile-time constant:
 protected MyType(Serialization info, StreamingContext cntxt)
 {
     int storedVersion = info.GetInt32("VERSION");
     switch(storedVersion)
     {
         case Version2_0:
             readVersion2(info, cntxt);
             break;
         case Version1_1:
             readVersion1Dot1(info, cntxt);
             break;
         // etc.
     }
 }

 // Write the current version
 [SecurityPermissionAttribute(SecurityAction.Demand, SerializationFormatter = true)]
 void ISerializable.GetObjectData(SerializationInfo inf, StreamingContext cxt)
 {
     // use runtime constant for current version:
     inf.AddValue("VERSION", CurrentVersion);
     // write remaining elements...
 }

　　相比之下，const最终优于readonly的地方就是性能。使用已知常量值要比访问readonly值略微高效一些。

　　不过这其中的效率提升可以说是微乎其微，而这样却能降低很多的灵活性。

　　若是你最终还是计划要放弃灵活性，那么在决定之前一定要对两者的性能差别做一个实际的测试。

　　在使用具名和可选参数时，你也会遇到同样的运行时/编译期常量的取舍。

　　可选参数的默认值将被放置于调用端，就像编译期常量（用const声明）的默认值一样。

　　正如选用readonly和const一样，在修改可选参数的值时也必须小心操作。

　　在编译期必须得到确定数值时一定要使用const。

　　例如特性（attribute）的参数和枚举的定义等，还有那些在各个版本发布之间不会变化的值。

　　在除此之外的所有情况下，都应尽量选择更加灵活的readonly常量。