关于对类的任何/所有实例成员使用 readonly 的想法？答案

【问题标题】：Thoughts on the use of readonly for any/all instance members of a class?关于对类的任何/所有实例成员使用 readonly 的想法？
【发布时间】：2009-09-15 18:12:15
【问题描述】：

前言

一段时间以来，我一直在对几乎所有类字段使用 readonly 修饰符。我将它用于 List 成员、IDisposeable 成员、整数、字符串等......除了我打算更改的值类型之外的所有内容。即使我通常想在 Dispose() 上将成员设为空，我也倾向于这样做。恕我直言，不需要 if 语句来测试 null 或已处置条件的优势大大超过了“可能”多次处置的对象的“潜在”麻烦。

问题

你什么时候使用只读的，或者你呢？

您或您的公司是否有任何关于使用只读的最佳实践和/或编码标准？

我很想听听您对以下示例课程的看法，一般概念是否是一种好习惯？

class FileReaderWriter : IFileReaderWriter, IDisposable
{
    private readonly string _file;
    private readonly Stream _io;

    public FileReaderWriter(string path) 
    {
        _io = File.Open(_file = Check.NotEmpty(path), FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None);
    }
    public void Dispose() { _io.Dispose(); }
    ...
}

【问题讨论】：

Effective C# 1 对此有一个项目。我强烈推荐 Effective C# 系列。

标签： c# .net coding-style

【解决方案1】：

在代码将成功编译的任何情况下，我都在字段上使用只读。

为什么？很简单，如果一个字段引用/值突然从不改变变为改变，它可能会违反类和消费者的微妙假设。因此，我希望对这种变化保持警惕，以评估这种新行为的影响。

【讨论】：

我同意你的推理，通常会更进一步，寻求将每个字段标记为只读，并在仔细考虑后才放宽约束。也许是我想得太远了。
@csharptest.net，这几乎就是我能走多远。我在这个问题上相当迂腐，我敢肯定我偶尔会过火。但是我已经看到太多由于对引用的不必要更改而导致的错误，所以我更喜欢安全的路线。
这是否意味着您永远不会或几乎永远不会使用像 public string SomewhatReadOnlyName { get; private set; } 这样的自动属性？

【解决方案2】：

和你一样，我尽可能使用readonly。在可能的情况下，我也使用不可变集合。

Dispose 是一个有趣的，因为它有效地将类型从“可用”变为“不可用”——我很想有一个非只读的bool 成员来表明这一点。再说一次，我很少发现自己需要实现IDisposable。通常我在使用资源时，只针对单个方法的过程，所以我将资源设置为该方法的本地。

【讨论】：

虽然我同意 Dispose() 是对象的突变，但我认为它类似于 C++ 删除运算符...本质上，对象在被处理/删除后的行为是未定义的。你不同意吗？
@Jon，这是否意味着您永远不会或几乎永远不会使用像 public string SomewhatReadOnlyName { get; private set; } 这样的自动属性？
@DanM：如果我很懒惰，或者我真的希望能够在内部对其进行变异，我只会使用这种形式。

【解决方案3】：

readonly 关键字只是 .NET 工具箱中的另一个工具。因此，在适用的地方使用它！一般来说，您希望最少访问属性，

原因是您希望保护您的代码不被从您不打算访问的地方调用/访问。所以回到您的readonly 问题，如果您的类成员只能从构造函数中修改（设置）一次，那么readonly 就是这样做的方法。

【讨论】：

【解决方案4】：

我们公司没有任何关于 readonly 的官方编码标准，但我们的团队普遍同意在可能的情况下和有意义的地方（经常）使用它。它清楚地表明了程序员或规范的意图，即一旦设置就不会更改。

我们中的一些人还使用 Resharper，它往往会提醒您经常使用它。因此，您的示例课程将被我们团队视为“良好实践”。

【讨论】：

【解决方案5】：

为了更短的代码，我没有把它放进去，但只有如果我有一个可以防止滥用的静态分析工具。

例如，在使用 Java 编写代码时，我依靠 PMD 来确保我不会因为没有将所有参数都声明为 final 而导致自己陷入困境。

您可以正确地争辩说，使用 readonly/final 会更快地通知您您的错误，但我已经这样做了足够长的时间，以至于我的蜘蛛侠意识在写作时就会消失，如果我碰巧错过了静态分析工具让我想起了它。

【讨论】：

【解决方案6】：

与其他几个回复者一样，我经常使用readonly。幸运的是Resharper 非常热衷于发现何时可以成为readonly 的成员。它向代码的读者展示了这个值是在实例创建后设置的，这是一个有价值的细节 imo。

【讨论】：