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

Question

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

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

int myBlorgleCount = 0;

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

int myBlorgleCount;

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

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

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

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

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

Answer 1

Я бы их не инициализировал. Если вы держите объявление как можно ближе к первому использованию, тогда не должно быть никакой путаницы.

Answer 2

Я бы этого не делал. В любом случае C # инициализирует int нулем, поэтому две строки функционально эквивалентны. Один просто длиннее и избыточнее, хотя и более нагляден для программиста, который не знает C #.

Answer 3

Я обычно делаю это для строк и в некоторых случаях для коллекций, где я не хочу, чтобы нули плавали вокруг. Общее мнение, в котором я работаю: «Не делать это явно для типов значений».

Answer 4

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

Answer 5

Это помечено как независимое от языка, но большинство ответов касаются C #.

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

Answer 6

Если в поле часто будут храниться новые значения без учета того, что было там ранее, и если оно должно вести себя так, как будто ноль был сохранен там изначально, но в нуле нет ничего «особенного», то значение должно быть сохранено явно.

Если поле представляет счет или сумму, для которой никогда не будет записано ненулевое значение, а вместо этого будут всегда добавляться или вычитаться другие суммы, то ноль следует считать «пустым» значением, и, следовательно, необходимо не может быть прямо указано.

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

1. `if (xposition! = 0) ...
2. `if ((flags & WoozleModes.deluxe)! = 0) ...

В первом сценарии сравнение с буквальным нулем имеет смысл, поскольку оно проверяет позицию, которая семантически ничем не отличается от любой другой. Во втором сценарии, однако, я бы предположил, что сравнение с буквальным нулем ничего не добавляет к удобочитаемости, потому что на самом деле код не интересуется, является ли значение выражения (flags & WoozleModes.deluxe) числом, отличным от нуля, а скорее это "не пусто".

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

Answer 7

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

В старых и неизменных языках ожидается, что значение неизвестно. Это ожидание сохраняется программистами из этих языков.

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

Пока, я думаю, что это прекрасно, чтобы инициализировать значение; то, что когда-то было неявным, становится явным. В долгосрочной перспективе, скажем, в ближайшие 10–20 лет люди могут начать понимать, что значение по умолчанию возможно, ожидаемо и известно - особенно если они остаются согласованными для разных языков (например, пустая строка для строк, 0 для чисел) .