如果有的话，我们应该使用const吗？

Question

Const被添加到客户端代码中。 Readonly不是。但是const更快。可能只是略有一点。

问题是，您是否应该选择const而不是readonly？或者换句话说，使用readonly代替const（请记住上述烘焙用品），我们实际上总是更好吗？

Answer 1

我认为唯一一次“const”是合适的是当你编写的规范比你正在编写的程序更持久时。例如，如果您正在实现HTTP协议，那么拥有“GET”的const成员是合适的，因为它永远不会改变，并且客户端当然可以将其硬编码到他们编译的应用程序中而不必担心您需要更改价值以后。

如果您有任何机会需要在将来的版本中更改值，请不要使用const。

哦！除非你已经测量过，否则永远不要认为const比readonly字段快。有JIT优化可能会使它实际上完全相同。

Answer 2

Const vs readonly：

  

关于差异的快速概要   在C＃中'const'和'readonly'之间：   '常量'：

     

  
• 不能是静止的。
  
• 在 编译时评估值。
  
• 仅在声明时宣传。
  

     

'只读'：

     

  
• 可以是实例级也可以是静态的。
  
• 在 运行时评估值。
  
• 可以在声明中或在构造函数中的代码中初始化。
  

更正：以上状态const不能是静态的。这是用词不当。他们不能应用静态关键字，因为它们已经是静态的。

因此，对于要在编译时评估的静态项，请使用const。

Answer 3

您可以在switch语句fwiw。

中使用const值作为大小写

Answer 4

当初始化不直接时，

readonly非常有用 在编译之前确定值时，可以使用const。

在某种程度上，readonly是一个运行时const＆amp; const是编译时常量值。

编辑：如果您使用www.koders.com查看一些代码，您会发现readonly可以使用const。我认为，其背后的原因可能是它在构造函数中是可修改的（如果需要）。对于const（特别是public），您有可能根据代码破坏客户端代码。

Answer 5

我通常只将const用于我知道永远不会改变的事物，例如真空中的光速。

我更喜欢readonly用于可能更改的内容。这样我只需要在发生更改时重新编译一个dll。这个经验法则的一个例外是该变量是私有/受保护/对其自己的程序集友好。在这些情况下，使用const是安全的。

Answer 6

const不能用于类或结构（字符串常量除外，如Skeet先生指出的那样），仅用于值类型并作为静态字段访问。 const的值在编译时设置，必须在声明时设置。

readonly可用于除枚举之外的任何内容，可以是静态字段或实例字段。 readonly的值在运行时设置，可以根据调用的构造函数进行不同的设置。

Here's a good page概述了const，readonly和static关键字。

Answer 7

您应该首选在编译时测试的修饰符，而不是在运行时测试的修饰符（在此上下文中为const over readonly）。您应该始终使用支持所需语义的修饰符。 如果不想修改某些东西 - 保护它或某人会写一些东西（偶然或无知）。

Answer 8

只要您可以在声明中设置值，就可以使用const，而不必等待构造函数。

Answer 9

很好地使用const是键/值对的键。例如，如果您仍在使用AppSetting（而不是ApplicationSettings），那么加载配置设置的密钥名称实际上没有意义。如果它在多个地方使用，请将Key粘贴在const。

中

Answer 10

当您的字段为简单类型（数字，布尔值或字符串）且其值永远不会更改时，请使用const。如果更改它们的值，则应重新编译项目。

使用readonly字段从其他来源初始化的字段（文件，数据库或其他代码，.. etc。），但不会更改。

要要让所有实例共享它们，请使用static readonly字段。

Answer 11

我发现用于const的一种特殊用法是可重复使用的属性中使用的“魔术”字符串，因为它们只能是const，因此不能使用静态只读。

我的特殊用例是ASP.NET授权属性

{{1}}