Инициализация строки по умолчанию: NULL или Empty? [закрыто]

Я всегда инициализировал свои строки значением NULL, полагая, что NULL означает отсутствие значения, а "" или String.Empty является допустимым значением. В последнее время я видел больше примеров кода, где String.Empty считается значением по умолчанию или не представляет никакого значения. Это кажется мне странным: с новыми добавленными в C # типами, допускающими значение NULL, кажется, что мы делаем шаг назад со строками, не используя NULL для представления «Нет значения».

Что вы используете в качестве инициализатора по умолчанию и почему?

Изменить: на основе ответов я продолжаю свои дальнейшие мысли

1. Как избежать обработки ошибок Если значение не должно быть нулевым, почему оно было установлено NULLв первую очередь? Может быть, было бы лучше идентифицировать ошибку в том месте, где она возникает, а не скрывать ее в остальной части вашей кодовой базы?

2. Избегание нулевых проверок Если вы устали выполнять нулевые проверки в коде, не лучше ли абстрагироваться от нулевых проверок? Возможно, обернуть (или расширить!) Строковые методы, чтобы сделать их NULLбезопасными? Что произойдет, если вы постоянно используете, String.Emptyа в вашу систему сработает нуль, вы все равно начнете добавлять NULLпроверки?

Не могу не вернуться к мнению, что это лень. Любой администратор баз данных дал бы вам девять глупостей, если бы вы использовали '' вместо nullего \ ее базы данных. Я думаю, что те же принципы применимы и в программировании, и должен быть кто-то, кто ударил бы по голове тех, кто использует, String.Emptyа не NULLпредставляет никакой ценности.

Смежные вопросы

• В C # следует ли использовать string.Empty или String.Empty или «»?
• В чем разница между String.Empty и «»
• Нулевая или пустая строка для представления данных в столбце таблицы?

+1 за различение между пустым и пустым. Я согласен с тем, что «пустой» должен означать «действительный, но пустой», а «NULL» должен означать «недействительный».

Поэтому я бы ответил на ваш вопрос так:

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

NULL, если это ошибка, если последующий код не устанавливает значение явно.

По данным MSDN :

Инициализируя строки Emptyзначением вместо null, вы можете снизить вероятность NullReferenceExceptionвозникновения.

IsNullOrEmpty()Тем не менее, всегда использовать - это хорошая практика.

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

Я это часто вижу:

string name = null; // or String.Empty
if (condition)
{
  name = "foo";
}
else
{
  name = "bar";
}

return name;

Не инициализировать значение null было бы столь же эффективно. Более того, чаще всего вам нужно присвоить значение. Инициализируя значение null, вы потенциально можете пропустить пути кода, которым не присваивается значение. Вот так:

string name = null; // or String.Empty
if (condition)
{
  name = "foo";
}
else if (othercondition)
{
  name = "bar";
}

return name; //returns null when condition and othercondition are false

Если вы не инициализируете значение null, компилятор выдаст ошибку, сообщающую, что не все пути кода присваивают значение. Конечно, это очень простой пример ...

Matthijs

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

if (s == "value")

У меня плохое предчувствие. Почему в этом методе есть строковый литерал? Что за настройка s? Знает ли он, что логика зависит от значения строки? Он знает, что для работы он должен быть строчными? Должен ли я исправить это, изменив его на использование String.Compare? Должен ли я создавать Enumи разбирать его?

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

Зная это, я не моргаю, когда вижу что-то вроде этого в нашей базе кода:

string msg = Validate(item);
if (msg != null)
{
   DisplayErrorMessage(msg);
   return;
}

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

Конечно, в остальном мире так не работает. Когда ваша программа имеет дело с пользовательским вводом, базами данных, файлами и т. Д., Вы должны учитывать другие философии. Вот и задача вашего кода - навести порядок в хаосе. Часть этого порядка - знать, когда должна означать пустая строка, String.Emptyа когда - null.

(Чтобы убедиться, что я не говорю из своей задницы, я просто искал в нашей кодовой базе `String.IsNullOrEmpty '. Все 54 его вхождения находятся в методах, которые обрабатывают ввод пользователя, возвращают значения из скриптов Python, исследуют значения, полученные из внешние API и т. д.)

На самом деле это зияющая дыра в языке C #. Невозможно определить строку, которая не может быть нулевой. Это вызывает такие простые проблемы, как та, которую вы описываете, что заставляет программистов принимать решение, которое им не нужно принимать, поскольку во многих случаях NULL и String.Empty означают одно и то же. Это, в свою очередь, может позже вынудить других программистов обрабатывать как NULL, так и String.Empty, что раздражает.

Более серьезная проблема заключается в том, что базы данных позволяют вам определять поля, которые сопоставляются со строкой C #, но поля базы данных могут быть определены как NOT NULL. Таким образом, невозможно точно представить, скажем, поле varchar (100) NOT NULL в SQL Server с использованием типа C #.

Другие языки, такие как Spec #, позволяют это.

На мой взгляд, неспособность C # определить строку, не допускающую null, так же плоха, как и его предыдущая неспособность определить int, которая допускает null.

Чтобы полностью ответить на ваш вопрос: я всегда использую пустую строку для инициализации по умолчанию, потому что она больше похожа на то, как работают типы данных базы данных. (Изменить: этот оператор был очень неясным. Он должен был гласить: «Я использую пустую строку для инициализации по умолчанию, когда NULL является избыточным состоянием, почти так же, как я установил столбец базы данных как NOT NULL, если NULL был бы лишним состоянием. , многие из моих столбцов БД настроены как NOT NULL, поэтому, когда я помещаю их в строку C #, строка будет пустой или иметь значение, но никогда не будет NULL. Другими словами, я только инициализирую строку NULL if null имеет значение, отличное от значения String.Empty, и я считаю, что этот случай менее распространен (но здесь люди привели законные примеры этого случая). ")

Это зависит.

Вам нужно знать, отсутствует ли значение (возможно ли, чтобы оно не было определено)?

Является ли пустая строка допустимым значением для использования этой строки?

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

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

похоже, что это частный случай http://en.wikipedia.org/wiki/Null_Object_pattern

Я либо устанавливаю его на "", либо на null - я всегда проверяю с помощью String.IsNullOrEmpty, так что все в порядке.

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

Я всегда объявляю строку с помощью string.empty;

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

Я всегда инициализирую их как NULL.

Я всегда использую, string.IsNullOrEmpty(someString)чтобы проверить его ценность.

Просто.

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

Я устанавливаю для строки значение null только тогда, когда мне нужно знать, была ли она установлена ​​или нет, и где пустая строка является чем-то допустимым для ее установки. На практике я нахожу такие ситуации редкими.

Пустая строка - это значение (кусок текста, который, кстати, не содержит букв). Null означает отсутствие ценности.

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

Повторяя ответ Томалака, имейте в виду, что когда вы присваиваете строковой переменной начальное значение null, ваша переменная больше не является строковым объектом; то же самое с любым объектом в C #. Итак, если вы попытаетесь получить доступ к любым методам или свойствам для своей переменной и предполагаете, что это строковый объект, вы получите исключение NullReferenceException.

Null следует использовать только в тех случаях, когда значение не является обязательным. Если значение не является необязательным (например, «Имя» или «Адрес»), оно никогда не должно быть нулевым. Это относится к базам данных, а также к POCO и пользовательскому интерфейсу. Null означает, что «это значение является необязательным и в настоящее время отсутствует».

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

Лично я предпочел бы, чтобы строки не допускали значения NULL по умолчанию, а вместо этого допускали бы значение NULL только в том случае, если мы объявим «строку?». Хотя, возможно, это невозможно или логично на более глубоком уровне; Точно сказать не могу.

Строки не являются типами значений и никогда ими не будут ;-)

Я думаю, что нет причин не использовать null для неназначенного (или в этом месте в потоке программы) значения. Если хотите различать, там == null. Если вы просто хотите проверить определенное значение и вас не волнует, является ли оно нулевым или другим, String.Equals ("XXX", MyStringVar) прекрасно подойдет.