《Effective C#》條款2：運行時常量（readonly）優於編譯時常量（const）

條款2：運行時常量（readonly）優於編譯時常量（const）
結論：只有當某些情況要求變量的值必須在編譯時可用，才應該考慮使用const，例如：特性（attribute）類的參數，枚舉定義，以及某些不隨組件版本變化而改變的值。否則，對於其他任何情況，都應該優先選擇readonly常量，從而獲得其所具有的靈活性。
基礎語法：
C#語言有兩種不同的常量機制：一種為編譯時（compile-time）常量，一種為運行時（runtime）常量。使用readonly關鍵字來聲明運行時常量，用const關鍵字來聲明編譯時常量。


// 編譯時常量：
public const int _Millennium = 2000;
// 運行時常量：
public static readonly int _ThisYear = 2004;

    特點差異：

編譯時常量與運行時常量行為的不同處在於它們的訪問方式。編譯時常量在編譯後的結果代碼中會被替換為該常量的值，運行時常量的值則在運行時對readonly變量（而非它的值）進行引用。

編譯時常量只可以用於基元類型（包括內建的整數類型和浮點類型）、枚舉類型或字符串類型。只讀（read-only）字段的類型就沒有任何限制。

性能比較：

使用const較之於使用readonly的唯一好處就是性能：使用已知常量值的代碼效率要比訪問readonly值的代碼效率稍好一點。但是這其中的效率提升是非常小的，大家應該和其所失去的靈活性進行一番權衡比較。在打算放棄靈活性之前，一定要對兩者的性能差別做一個評測。

討論：

這一條款裡面說到了使用Const會造成的一種錯誤：在兩個項目中，一個項目定義了一個Const常量，另一個項目使用這個常量；如果對常量的值進行修改，而對使用的項目不進行編譯則會出現另一個項目中還是修改以前的值。通過上面的語法解釋就很好理解因為編譯後的結果代碼中會被替換為該常量的值造成的。Readonly則不會出現這個問題；

上面說的在實際的項目進行中不太會出現這樣的問題；你對版本的更新總是要Release以後來部署的，這個過程就是對整個項目的一個編譯過程；當然你在調試過程中是會出現這個問題的。