Мысли об использовании readonly для любых / всех экземпляров класса?

Question

Введение

В течение некоторого времени я использовал модификатор readonly почти для всех полей класса. Я использую его для членов List , IDisposeable членов, целых, строк и т. Д. ... всего, кроме типов значений, которые я намерен изменить. Я склонен делать это, даже когда я обычно хотел бы обнулить член в Dispose (). ИМХО Преимущества отсутствия необходимости в операторах if для проверки на нулевые или удаленные условия значительно перевешивают «потенциал» для проблем в объектах, которые «могли бы» быть устранены несколько раз.

Вопрос

Когда вы используете readonly, или вы?

Есть ли у вас или вашей компании какие-либо передовые практики и / или стандарты кодирования, касающиеся использования только для чтения?

Мне любопытно услышать ваши мысли о следующем учебном классе, является ли общая концепция хорошей практикой или нет?

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(); }
    ...
}

Answer 1

Я использую readonly для полей в любой ситуации, когда код будет успешно скомпилирован.

Почему? Просто, если ссылка / значение поля внезапно переходит от того, чтобы никогда не изменяться к изменению, это может нарушить тонкие предположения в классе и потребителях. Поэтому я хочу быть предупрежденным об этом изменении, чтобы оценить последствия этого нового поведения.

Answer 2

Как и вы, я использую readonly везде, где могу. Там, где это возможно, я тоже использую неизменные коллекции.

Dispose является интересным, потому что он фактически изменяет тип с «пригодный для использования» на «непригодный для использования» - я бы соблазнился иметь не-только для чтения элемент bool, чтобы указать это. Опять же, я редко обнаруживаю, что мне нужно реализовать IDisposable. Обычно, когда я использую ресурсы, это только для одного метода, поэтому я делаю ресурс локальным для этого метода.

Answer 3

Ключевое слово readonly - это просто еще один инструмент в вашем наборе инструментов .NET. Поэтому используйте его там, где это применимо! Как правило, вы хотите увеличить минимум доступа к свойствам

Причина в том, что вы хотите защитить свой код от вызова / доступа из тех мест, откуда вы не предполагали, что он будет доступен. Итак, возвращаясь к вашему readonly вопросу, если у вас есть член класса, который нужно только изменить (установить) один раз из конструктора, тогда readonly - способ сделать это.

Answer 4

Как и несколько других репортеров, я использую readonly очень часто. К счастью Resharper очень заинтересован в поиске, когда члены могут быть сделаны readonly. Он показывает читателю кода, что это значение устанавливается после создания экземпляра, что является ценной деталью imo.

Answer 5

Ради более короткого кода я его не вставляю, но только , если у меня есть инструмент статического анализа, который защитит от неправильного использования.

Например, при написании на Java я полагаюсь на PMD, чтобы убедиться, что я не стреляю себе в ногу, не объявляя все свои параметры как окончательные.

Вы могли бы, правильно, утверждать, что использование readonly / final скорее сообщит вам о вашей ошибке, но я делал это достаточно долго, чтобы мое чувство пауков исчезло во время записи, и если я что-то упустил, статический анализ инструмент напоминает мне об этом.

Answer 6

В нашей компании нет никаких официальных стандартов кодирования, касающихся readonly, но наша команда всегда соглашается использовать его, когда это возможно и там, где это имеет смысл (что часто бывает). Это ясно указывает на намерение программиста или спецификацию, что это не должно быть изменено после того, как оно установлено.

Некоторые из нас также используют Resharper, который напоминает вам использовать его совсем немного. Таким образом, ваш пример класса будет чем-то, что будет считаться «хорошей практикой» в нашей команде.