Const
被烘焙到客户端代码中。Readonly
不是。但是const
速度更快。可能只是轻微的。
const
问题是,有没有你更喜欢的场景readonly
?或者换种说法,我们实际上不是总是readonly
用 a代替 a更好const
吗(记住上面所说的烘焙)?
我相信“const”唯一合适的时候是当你编写的规范比你正在编写的程序更耐用时。例如,如果您正在实现 HTTP 协议,则为“GET”设置一个 const 成员是合适的,因为它永远不会改变,并且客户端当然可以将其硬编码到他们编译的应用程序中,而不必担心您需要更改以后值。
如果您有任何机会在未来的版本中更改该值,请不要使用 const。
哦!除非你已经测量过,否则永远不要假设 const 比只读字段快。有 JIT 优化可以做到这一点,所以它实际上是完全一样的。
关于 C# 中 'const' 和 'readonly' 之间区别的快速概要:'const':
- 不能是静态的。
- 在编译时评估值。
- 仅在声明时初始化。
'只读':
- 可以是实例级的或静态的。
- 在运行时评估值。
- 可以在声明中初始化,也可以通过构造函数中的代码初始化。
更正:上述状态 const 不能是静态的。那是用词不当。它们不能应用 static 关键字,因为它们已经是静态的。
因此,您将 const 用于要在编译时评估的静态项目。
您可以在 switch 语句中使用 const 值作为 case,fwiw。
当初始化不直接时, readonly 很有用。
当您在编译之前确定该值时,可以使用 const。
在某种程度上, readonly 是一个运行时常量 & const 是一个编译时常量值。
编辑:如果您使用 www.koders.com 查看一些代码,您会发现在可以使用 const 的地方使用 readonly。我认为,其背后的原因可能是它可以在构造函数中修改(如果需要)。在 const (尤其是 public)的情况下,您有机会根据您的代码破坏客户端代码。
我通常只将 const 用于我知道永远不会改变的事情,例如真空中的光速。
对于可能发生变化的事情,我更喜欢 readonly 。这样,如果发生更改,我只需要重新编译一个 dll。这个经验法则的一个例外是变量是否对其自己的程序集是私有的/受保护的/友好的。在这些情况下,使用 const 是安全的。
const 不能用于类或结构(字符串常量和 null 除外,正如 Skeet 先生指出的那样),只能用于值类型并作为静态字段访问。const 的值在编译时设置,并且必须在声明时设置。
readonly 可用于除枚举之外的任何内容,并且可以是静态字段或实例字段。只读的值是在运行时设置的,可以根据调用的构造函数进行不同的设置。
这是 const、readonly 和 static 关键字概述的好页面。
您应该更喜欢在编译时测试的修饰符,而不是在运行时测试的修饰符(在这种情况下 const 而不是 readonly)。并且您应该始终使用支持您需要的语义的修饰符。如果某些东西不打算被修改 - 保护它,否则有人会写一些东西(偶然或无知)。
只要可以在声明中设置值并且不必等待构造函数,就应该使用 const。
const 的一个很好的用途是用于键/值对的键。例如,如果您仍在使用 AppSetting(而不是 ApplicationSettings),则将密钥的名称加载到配置设置中没有任何意义。如果在多个地方使用,请将 Key 粘贴在 const 中。
const
当您的字段是简单类型(数字、布尔值或字符串)并且它们的值永远不会更改时使用。如果更改它们的值,则应重新编译项目。
当它们从另一个源(文件、数据库或其他代码、..等)初始化时使用readonly
字段,但它们不会被更改。
当您想让它们被所有实例共享时使用static readonly
字段。
我发现 const 的一个特殊用途是属性中使用的可重用“魔术”字符串,因为它们只能是 const,你不能使用静态只读。
我的特殊用例是 ASP.NET 授权属性
[Authorize(Roles = Roles.FirstParty)]