什么時候，如果有的話，我們應該使用 const 嗎？

Question

Const被嵌入到客戶端代碼中。 Readonly不是。 但是const更快。 可能只是輕微的。

問題是，是否有任何情況您應該更喜歡const不是readonly ？ 或者換個說法，我們實際上是否總是最好使用readonly而不是const （記住上述烘焙的東西）？

Answer 1

我相信“const”唯一合適的時間是當您編碼的規范比您正在編寫的程序更持久時。 例如，如果您正在實現 HTTP 協議，那么為“GET”設置一個 const 成員是合適的，因為這永遠不會改變，並且客戶當然可以將其硬編碼到他們編譯的應用程序中，而不必擔心您需要更改值后。

如果您需要在將來的版本中更改該值，請不要使用 const。

哦！ 並且永遠不要假設 const 比只讀字段快，除非你已經測量過它。 有一些 JIT 優化可能會使其實際上完全相同。

Answer 2

常量與只讀：

C# 中“const”和“readonly”之間差異的簡要概述：“const”：

• 不能是靜態的。
• 在編譯時評估值。
• 僅在聲明時初始化。

'只讀'：

• 可以是實例級或靜態。
• 在運行時評估值。
• 可以在聲明或構造函數中的代碼中初始化。

更正：上述狀態 const 不能是靜態的。 那是用詞不當。 它們不能應用 static 關鍵字，因為它們已經是靜態的。

因此，您將 const 用於要在編譯時評估的靜態項目。

Answer 3

您可以在 switch 語句 fwiw 中使用 const 值作為案例。

Answer 4

readonly 在初始化不直接時很有用。
當您在編譯之前確定該值時，可以使用 const。

在某種程度上， readonly 是運行時 const & const 是編譯時常量值。

編輯：如果您使用 www.koders.com 查看一些代碼，您會發現在可以使用 const 的地方使用了 readonly。 我認為，這背后的原因可能是它在構造函數中是可修改的（如果需要的話）。 在 const（尤其是公共）的情況下，您有機會破壞依賴於您的代碼的客戶端代碼。

Answer 5

我通常只將 const 用於我知道永遠不會改變的事物，例如真空中的光速。

我更喜歡 readonly 可能會改變的事情。 這樣，如果發生更改，我只需要重新編譯一個 dll。 此經驗法則的一個例外是變量是否對其自己的程序集是私有的/受保護的/友好的。 在這些情況下，使用 const 是安全的。

Answer 6

const 不能用於類或結構（除了字符串常量和 null，正如 Skeet 先生指出的那樣），只能用於值類型並且作為靜態字段訪問。 const 的值在編譯時設置，並且必須在聲明時設置。

readonly 可用於除枚舉之外的任何內容，並且可以是靜態或實例字段。 readonly 的值是在運行時設置的，可以根據調用的構造函數進行不同的設置。

這是一個很好的頁面，用於概述 const、readonly 和 static 關鍵字。

Answer 7

您應該更喜歡在編譯時測試的修飾符而不是在運行時測試的修飾符（在這種情況下，const 而不是 readonly）。 並且您應該始終使用支持您需要的語義的修飾符。 如果某些東西不打算修改 - 保護它，否則有人會寫一些東西（偶然或無知）。

Answer 8

只要可以在聲明中設置值並且不必等待構造函數，就應該使用 const。

Answer 9

const 的一個很好的用途是用於鍵/值對的鍵。 例如，如果您仍在使用 AppSetting（而不是 ApplicationSettings），那么將密鑰的名稱加載到配置設置中實際上沒有意義。 如果它在多個地方使用，請將 Key 粘貼在 const 中。

Answer 10

當您的字段是簡單類型（數字、布爾值或字符串）並且它們的值永遠不會改變時，請使用const 。 如果更改它們的值，則應重新編譯項目。

當它們從另一個源（文件、數據庫或其他代碼，.. 等）初始化時使用readonly字段，但它們不會被更改。

當您想讓所有實例共享static readonly字段時，請使用它們。

Answer 11

我發現 const 的一個特殊用途是在屬性中使用的可重用“魔法”字符串，因為它們只能是 const，不能使用靜態只讀。

我的特殊用例是 ASP.NET 授權屬性

[Authorize(Roles = Roles.FirstParty)]