Должен ли я всегда / никогда / никогда не инициализировать поля объекта значениями по умолчанию?

Question

Вопрос по стилю кода здесь.

Я посмотрел на этот вопрос, который спрашивает, действительно ли .NET CLR всегда инициализирует значения полей. (Ответ да .) Но меня поражает, что я не уверен, что это всегда хорошая идея сделать это. Я думаю, что если я увижу заявление, подобное этому:

int myBlorgleCount = 0;

У меня довольно хорошая идея, что программист ожидает, что счет начнется с нуля, и с этим все в порядке, по крайней мере, в ближайшем будущем. С другой стороны, если я просто увижу:

int myBlorgleCount;

У меня нет ни малейшего представления, является ли 0 допустимым или разумным значением. И если программист только начинает читать и изменять его, я не знаю, намеревался ли программист начать использовать его до того, как он установит для него значение, или он ожидал, что он будет равен нулю и т. Д.

С другой стороны, некоторые довольно умные люди и утилита очистки кода Visual Studio говорят мне, чтобы удалить эти избыточные объявления. Каково общее согласие по этому вопросу? (Есть консенсус?)

Я пометил это как независимость от языка, но если есть какой-то странный случай, когда это определенно хорошая идея пойти против фактуры для конкретного языка, это, вероятно, стоит указать.

РЕДАКТИРОВАТЬ : Хотя я и говорил, что этот вопрос не зависит от языка, он, очевидно, не применим к таким языкам, как C, где инициализация значений не производится.

РЕДАКТИРОВАТЬ : Я ценю ответ Джона, но это именно то, что я не ищу. Я понимаю, что .NET (или Java или что-то еще) выполнит эту работу и последовательно и правильно инициализирует значения. Я хочу сказать, что если я вижу код, который изменяет значение, которое ранее не было явно задано в коде, я, как сопровождающий код, не знаю, имел ли исходный кодер значение по умолчанию, или просто забыл установить значение, или ожидал, что оно будет установлено где-то еще и т. д.

Answer 1

Подумайте о долгосрочном обслуживании.

• Сохраняйте код как можно более явным.
• Не полагайтесь на специфичные для языка способы инициализации, если это не нужно. Может быть, более новая версия языка будет работать по-другому?
• Будущие программисты будут вам благодарны.
• Менеджмент поблагодарит вас.
• Зачем запутывать вещи даже малейшим?

Обновление: Будущие сопровождающие могут прийти из другого фона. Дело не в том, что «правильно», а в том, что будет легче в долгосрочной перспективе.

Answer 2

Вы всегда уверены, что платформа работает так, как работает платформа. Платформа .NET инициализирует все поля значениями по умолчанию. Если вы видите поле, которое не инициализируется кодом, это означает, что поле инициализируется CLR, а не то, что оно не инициализировано.

Это относится к платформам, которые не гарантируют инициализацию, но не здесь. В .NET чаще всего указывает на незнание со стороны разработчика, думая, что инициализация необходима.

---

Еще одно ненужное похмелье из прошлого:

string foo = null;
foo = MethodCall();

Я видел это от людей, которые должны знать лучше.

Answer 3

Я думаю, что это нужно сделать, если это действительно поможет сделать код более понятным.

Но я думаю, что это общая проблема со всеми языковыми функциями. Мое мнение по этому поводу таково: Если это официальная функция языка, вы можете использовать ее. (Конечно, есть некоторые анти-функции, которые следует использовать с осторожностью или избегать, например, отсутствующие option explicit в Visual Basic или наследование алмазов в C ++)

Было время, когда я был очень параноиком и добавил всевозможные ненужные инициализации, явные приведения, блоки über-paranoid try-finally ... Однажды я даже думал об игнорировании автобокса и замене всех вхождений явным типом преобразования, просто «чтобы быть на безопасной стороне».

Проблема в том, что конца нет. Вы можете избежать почти всех языковых возможностей, потому что не хотите им доверять.

Помните: это только магия, пока вы не поймете это :)

Answer 4

Я думаю, что имеет смысл инициализировать значения, если это проясняет намерения разработчика.

В C # нет никаких накладных расходов, так как все значения все равно инициализируются. В C / C ++ неинициализированные значения будут содержать мусор / неизвестные значения (что бы ни находилось в ячейке памяти), поэтому инициализация была более важной.

Answer 5

Я согласен с вами; это может быть многословно, но мне нравится видеть:

int myBlorgleCount = 0;

Теперь я всегда исходные строки:

string myString = string.Empty;

(я просто ненавижу нулевые строки.)

Answer 6

Из моего опыта я обнаружил, что явная инициализация локальных переменных (в .NET) добавляет больше беспорядка, чем ясности.

Переменные всего класса, с другой стороны, всегда должны быть инициализированы. В прошлом мы определяли общесистемные пользовательские «нулевые» значения для общих типов переменных. Таким образом, мы всегда могли знать, что было инициализировано по ошибке, а что было инициализировано специально.

Answer 7

В случае, если я не могу сразу установить что-то полезное

int myValue = SomeMethod();

Я установлю его на 0. Это больше, чтобы не думать о том, какое значение будет в противном случае. Для меня тот факт, что целые числа всегда установлены в 0, не на кончике моих пальцев, поэтому, когда я вижу

int myValue;

мне понадобится секунда, чтобы раскрыть этот факт и вспомнить, к чему он будет установлен, нарушая мой мыслительный процесс. Для тех, кто обладает этими знаниями, они могут встретить

int myValue = 0;

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

Сделайте то, что всегда имеет смысл как для вас, так и для команды, в которой вы работаете. Если обычной практикой является установка этого, то установите его, в противном случае - нет.

Answer 8

Я всегда инициализирую поля явно в конструкторе. Для меня это место, чтобы сделать это.

Answer 9

http://www.geekherocomic.com/2009/07/27/common-pitfalls-initialize-your-variables/

Answer 10

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

public int Count { get; set; }