В C# следует ли использовать string.Empty или String.Empty или "" для инициализации строки?
В C# я хочу инициализировать строковое значение пустой строкой.
Как мне это сделать? Каков правильный путь и почему?
string willi = string.Empty;
или же
string willi = String.Empty;
или же
string willi = "";
или что?
Что еще важнее, никогда не сравнивать строку с Sting.Empty. <br> Плохо: if (s == "") <br> Хорошо: if (s.Length == 0)
лучше использовать String.IsNullOrEmpty (string myString), хотя, конечно?
Я использую [string.IsNullOrWhiteSpace (stringvalue)] ... работает в .Net 4.0. Для инициализации я просто использую: [var text = "";] Простой, читаемый и минимальный ввод времени :)
Что еще важнее, так это веселое имя вашей переменной.
Что меня интересовало, так это то, почему существует даже свойство Empty. Это хорошо и все такое, но не обязательно.
возможный дубликат В чем разница между String.Empty и "" (пустой строкой)?
там был разница stackoverflow.com/questions/16618302/…
@ZombieSheep Вы не можете использовать IsNullOrEmpty для установки значения строковой переменной ...
Также, если вы используете обфускацию кода. string.empty может быть запутан, а как "" не обфусцирован. Опять же, не большая разница и не имеет большого значения, если вы используете какую-то обфускацию, но это разница.
Ответы 30
Я лично предпочитаю "", если нет веских причин, для чего-то более сложного.
Любой из вышеперечисленных.
Есть много-много лучших вещей, которые стоит проповедовать. Например, какой цвет коры лучше всего подходит дереву, я думаю, неопределенно-коричневый с оттенками мягкого мха.
Я использую третий, но из двух других первый кажется менее странным. string - это псевдоним для String, но видеть их в назначении кажется неприятным.
В конечном итоге компилятор должен сделать их одинаковыми. Выберите стандарт, чтобы ваш код было легко читать, и придерживайтесь его.
Я думаю, что второе «правильное», но, честно говоря, не думаю, что это будет иметь значение. Компилятор должен быть достаточно умен, чтобы скомпилировать любой из них в один и тот же байт-код. Я сам использую "".
Я бы предпочел stringString. Выбор string.Empty вместо "" - это вопрос выбора одного из них и его приверженности. Преимущество использования string.Empty состоит в том, что вам очень очевидно, что вы имеете в виду, и вы случайно не скопируете непечатаемые символы, такие как "\x003", в свой "".
Я бы сказал, что если вы случайно копируете непечатаемые символы в свой код, у вас проблемы посерьезнее, чем этот вопрос;)
ASCII \ 003 является разделителем полей для сообщений B2B, с которыми я работал :)
(Я бы также посоветовал избегать \ x escape, кстати - слишком сложно заметить разницу между "\ x9Bad Compiler" и "\ x9Good Compiler", у которых радикально разные результаты!)
Лично я предпочитаю String при вызове статического метода для String. Однако я почти слепой, и это личное предпочтение, которое я никому не навязываю.
Я бы, вероятно, объявил const над "\x003". :)
Меня укусило нечто подобное, где у меня есть документ со строками с непечатаемыми символами в новом задании ... :)
Вы используете копирование / вставку для ввода "" ...?
@Timo Не воспринимайте этот пример буквально. Представьте, что он копирует кусок текста со встроенными непечатаемыми символами из документации API.
@ Джимми Конечно, но мы говорили о пустой строке. Я утверждаю, что аргумент о том, что "" опасен при копировании / вставке, недействителен, потому что вы никогда не копируете / вставляете пустую строку. Что касается других струн, это, конечно, всегда нужно помнить.
Я не имею значения. Последний вариант набирать быстрее всего :)
String.Empty и string.Empty эквивалентны. String - это имя класса BCL; string - это псевдоним C# (или ярлык, если хотите). То же, что и с Int32 и int. См. Дополнительные примеры в документы.
Что касается "", я не совсем уверен.
Лично я всегда использую string.Empty.
Мне подойдет любой из первых двух. Я бы избегал последнего, потому что относительно легко ввести ошибку, поставив пробел между кавычками. Эту конкретную ошибку было бы трудно найти путем наблюдения. При отсутствии опечаток все семантически эквивалентны.
[РЕДАКТИРОВАТЬ]
Кроме того, вы можете всегда использовать string или String для единообразия, но это только я.
Я согласен с этим замечанием, но я все еще живу опасно, когда я ленив. В любом случае, я не думаю, что у меня есть повод писать код, который использует строку перед назначением ей вне объявления переменной. На самом деле меня раздражает, что мне вообще приходится инициализировать свои строки, несмотря на риски.
string является синонимом типа System.String, они идентичны.
Значения также идентичны: string.Empty == String.Empty == ""
Я бы не стал использовать символьную константу "" в коде, скорее string.Empty или String.Empty - проще понять, что имел в виду программист.
Между string и String мне больше нравится нижний регистр string просто потому, что я много лет работал с Delphi, а стиль Delphi - строчный string.
Итак, если бы я был вашим начальником, вы бы написали string.Empty
Неважно - это одно и то же. Однако главное, чтобы вы должен быть последовательным
p.s. Я все время борюсь с такими «правильными вещами».
В современном мире «согласованность» означает согласованность во всех командах по всему миру, что является одной из целей StackOverflow. Если можно, давайте воспользуемся String.Empty.
В некоторых языках нет константы Empty, и все языки, которые я могу придумать, допускают "" строку нулевой длины. Поэтому я голосую за "" для согласованности с другими языками. :)
Лучший код - это вообще не код:
The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. […] Start with brevity. Increase the other dimensions as required by testing.
Следовательно, чем меньше кода, тем лучше код: предпочитайте ""string.Empty или String.Empty. Эти два - в шесть раз дольше без дополнительных преимуществ - конечно, без дополнительной ясности, поскольку они выражают одну и ту же информацию.
но в C# мы можем просто сказать string.IsNullOrWhitespace (s): p
Я согласен с тем, что код должен быть как можно меньше, но в целом я не стану утверждать, что меньшее количество символов - всегда лучший код. Например, когда дело доходит до именования переменных, разумное количество символов обычно приводит к лучшим именам, чем просто использование i и j.
@Markus Это сильно зависит: для переменной цикла, представляющей индекс, iявляется лучше, чем длинное имя переменной. Даже более общие, более короткие имена переменных которые передают ту же информацию, с той же ясностью, всегда предпочтительнее. Просто чтобы выразить необходимую информацию, вы необходимость определенной длины символа, и я не отрицаю этого (никто не отрицает).
@Konrad: i - хорошее имя переменной, только если цикл небольшой и не содержит никаких других индексов. Но я согласен, что если что-то. можно сформулировать более кратко, передав ту же информацию, которая была бы предпочтительнее, например, в случае string.Empty / "". Строка string.Empty не добавляет ясности.
Для меня: string.Empty говорит, что эта строка всегда и должна быть пустой, тогда как "" говорит, что во время записи эта строка может быть пустой, но вы можете ее изменить.
@aeroson Не стесняйтесь интерпретировать все так, как вы хотите, но имейте в виду, что никто другой не поделится вашим весьма своеобразным чтением, и поэтому не полагайтесь на него для передачи намерений: никто этого не получит.
@aeroson Строки неизменяемы, поэтому их нельзя менять. Если вы имеете в виду изменение того, что находится в Переменная, я бы не предполагал такого намерения из того, что изначально присвоено этой переменной.
Краткость всегда должна превосходить удобочитаемость. Есть причина, по которой разработчики фреймворка добавили String.Empty, и это не только из-за проблем с производительностью, но и для того, чтобы было очень ясно, какова цель. При сканировании кода его намного легче идентифицировать (и искать), чем "".
@DanDiplo Вы не можете всерьез утверждать, что String.Empty более читабелен, чем "". Это просто не, и вопреки вашему утверждению нет никаких доказательств того, что разработчики фреймворка так думают (я не могу читать их мысли, но я почти уверен, что они так не думают, и что, если что-то, они, вероятно, видят его присутствие как ошибка в ретроспективе). Давайте поговорим с Эриком Липпертом - хотя шансы прочитать это, вероятно, невелики.
@KonradRudolph В недавних примерах Microsoft для "Лучших практик использования строки в .NET Framework" используется String.Empty - см. docs.microsoft.com/en-us/dotnet/standard/base-types/…
Я не собирался вмешиваться, но я вижу, что здесь выкидывают некоторую неправильную информацию.
Я лично предпочитаю string.Empty. Это личное предпочтение, и я подчиняюсь воле любой команды, с которой работаю, в каждом конкретном случае.
Как отмечали некоторые другие, между string.Empty и String.Empty нет никакой разницы.
Кроме того, и это малоизвестный факт, использование "" вполне приемлемо. Каждый экземпляр "" в других средах создает объект. Однако .NET стажирует свои строки, поэтому будущие экземпляры будут извлекать ту же неизменяемую строку из внутреннего пула, и любое снижение производительности будет незначительным. Источник: Брэд Абрамс.
Я не понимаю, почему «технически» каждый экземпляр «» создает объект. Строки интернированы не случайно - это указано в спецификации C#.
Используйте то, что вы и ваша команда сочтете наиболее читаемым.
Другие ответы предполагали, что новая строка создается каждый раз, когда вы используете "". Это неверно - из-за интернирования строк он будет создан либо один раз для каждой сборки, либо один раз для каждого домена приложения (или, возможно, один раз для всего процесса - не уверен в этом). Эта разница незначительна - массово, массово незначительно.
Другое дело, что вы считаете более читаемым. Это субъективно и будет варьироваться от человека к человеку, поэтому я предлагаю вам выяснить, что нравится большинству людей в вашей команде, и все согласны с этим для единообразия. Лично мне "" легче читать.
Аргумент о том, что "" и " " легко спутать друг с другом, меня не волнует. Если вы не используете пропорциональный шрифт (а я не работал с разработчиками Любые, которые используют), разницу довольно легко заметить.
Ваши глаза могут обмануть вас, когда вы ожидаете увидеть "", вы легко можете принять "" за "". Вот почему легче редактировать то, что написал кто-то другой. У вашего мозга нет предвзятых представлений о тексте, поэтому вам легче выбрать анонимы.
@tvanfosson: Значит, вас (или вашего коллегу) на самом деле укусила эта ошибка? Я с подозрением отношусь к подобным заявлениям, хотя на самом деле они не вызывают проблем. Я использую "" много лет, но ни разу не ошибся ...
Джон, я использую Segoe UI 10 pt в VS. Красиво, вкладки в любом случае идеально выстраиваются, и таким образом у меня могут быть гораздо более длинные строки. Может я тогда не разработчик: D
@Alan: Я попробую посмотреть, на что это похоже. Лично я использую пробелы вместо вкладок (и буду сражаться за это до смерти;), что, как я подозреваю, делает его менее эффективным для выравнивания параметров битов и т. д... тем не менее, стоит попробовать.
Я постоянно использую string.Empty, поэтому нет. С другой стороны, я часто редактирую свои сообщения SO, потому что я ошибаюсь и дважды печатаю слова, которые не вижу, пока не опубликовал их. Я просто говорю, зачем рисковать. И нет, персонаж мне не платит.
Зачем рисковать? Потому что я считаю "" более читаемым, чем string.Empty. В противном случае я бы однозначно использовал последнее. Однако, учитывая определенные личные предпочтения по сравнению с риском потенциал, который меня никогда не укусил, я думаю, что разумно выбрать код, который команда считает наиболее читаемым.
@Jon: Я тоже использую пробелы вместо табуляции, я имел в виду не буквальные табуляции, а отступы. Простите за это. И, пожалуйста, попробуйте - раньше я был поклонником Courier New / Monaco / Lucida Sans Typewriter, но однажды попробовал Segoe UI и никогда не оглядывался назад :)
@Alan: На данный момент изменились. Можно использовать это для презентаций - приятно, чтобы на экране было больше, особенно когда шрифт весь взорван ...
@Jon: Если вы прочтете мой ответ, вы увидите, что я выразил личное предпочтение, на мой взгляд, по разумной причине. Вы не согласны. Возможно, когда вам исполнится 40 и ваше зрение вблизи начнет ухудшаться, вы сможете изменить свою точку зрения. :-)
@tvanfosson: Я изменю свою точку зрения, когда увижу доказательства того, что это вызывает реальную, а не предполагаемую проблему :) Я думаю, что утверждение, что внести ошибку относительно легко, когда такой ошибки не было замечено, является преувеличением. Но да, это все личное мнение.
Лично я всегда использовал String.Empty, я использую заглавную букву «S» всякий раз, когда хочу использовать статический метод для строки, это просто личное предпочтение, которое позволяет мне отличать тип от переменной. Но это всего лишь переход от использования StringUtils.EMPTY в commons.lang из java. Интересно то, что я почти слепой, и это определенно помогает мне с удобочитаемостью.
@Brett: С другой стороны, в Visual Studio «строка» имеет другой цвет. Как вы говорите, это личное предпочтение ...
Вы вдохновили меня начать разработку в Times New Roman.
Я думаю, что «проблема» не в том, что это вводит ошибки (у меня этого тоже никогда не было), а в том, что это менее читаемый и что вам иногда нужно посмотри дважды, независимо от того, инициализирована ли строка как пустая строка "" или как пробел " ". Конечно, довольно редко строка инициализируется пробелом, но я все равно часто проверяю это бессознательно. Поэтому я всегда выбираю String.Empty, потому что он понятен с первого взгляда.
@gehho: Ты считаю его менее читаемым - и это нормально - но я считаю его более читаемым, чем string.Empty. При использовании моноширинного шрифта разница между "" и "" для меня очень очевидна, а string.Empty излишне загроможден. Но на самом деле это просто личные предпочтения.
@Jon: Абсолютно - личные предпочтения! Я просто хотел ответить на ваш комментарий от Nov 4 '08 at 20:27, где вы спрашиваете, вводил ли он когда-нибудь ошибку. Дело не в том, что он вносит ошибки, а в том, что мне (подсознательно) нужно больше времени, чтобы интерпретировать его (это (милли) секунды, но все же ...). И я думаю, что другие, кто упоминал этот случай (например, Тванфоссон и Бретт Райан), имели в виду именно это. Я не хотел убеждать вас использовать String.Empty - я просто хотел объяснить причину, по которой некоторые люди предпочитают его. :)
① Я использую пропорциональный шрифт, и у меня нет проблем с отличием "" от " " (хотя, возможно, зависит от шрифта); ② Даже если бы их было трудно визуально различить, я думаю, что в целом из кода в контексте было бы ясно, какой именно код должен быть.
+1 для пропорционального шрифта, но да, нужно тщательно выбирать или редактировать шрифт вручную, так как у большинства из них слишком узкое пространство.
"" не очень похож на " ", но его можно спутать с '"'.
@Ben: Не могу сказать, что у меня когда-либо была проблема с этим ... тем более, что во многих случаях это было бы неверно из-за другого типа.
Лично я считаю, что мой мозг использует гораздо меньше возможностей для интерпретации простого шаблона "", чем для String.Empty («эй, есть класс и свойство - что он делает?») Все, кто использует String.Empty, также используют String.Space (1 )? Если нет места, которое трудно различить, то одно или несколько также могут быть.
Единственная вероятная путаница - между одной двойной кавычкой и двумя одинарными кавычками ... ("vs '') == WTF!?!?! Любой" компетентный "программист одинаково легко справится с ЛИБО var s = " "ИЛИ var s = String.Empty. Но, читая комментарии здесь ... приятно видеть подтверждение того, что у других людей есть патологические, квазирелигиозные представления о стиле программы, которые на самом деле не имеют значения, черт возьми. Я думал, что был один . Вздох.
Самым большим преимуществом string.Empty является то, что вы можете более легко найти точное его использование в среде IDE, такой как Visual Studio. Простая операция поиска для "" вернет экранированные кавычки и "" представление в комментариях, а также варианты использования, которые вы действительно ищете. Выполнение типа проверки кода "поиска использования" string.Empty предоставит вам все возможности его использования в рамках всего решения, тогда как поиск использования строкового литерала (например, "") ограничен объемом сборки, которую он определено в.
@MutantNinjaCodeMonkey: Я не могу припомнить, чтобы когда-либо искал "" в кодовой базе, и если бы я это делал, то мое использование "" в комментариях или дословных строковых литералах достаточно мало, чтобы меня это сильно не беспокоило. Если это действительно самое большое преимущество string.Empty, IMO это довольно крохотный.
Обсуждение предпочтений в программировании похоже на обсуждение предпочтений в еде. Одно невозможно доказать лучше другого, потому что нет разницы практичный с теми, кто его использует. Несомненно, что последовательное использование одного по сравнению с другим определенно вызовет у менее адаптивных людей небольшие трудности, когда им придется менять свои привычки, но, по правде говоря, предполагается, что разнообразие дает каждому человеку свободу развивать свои собственные привычки. стиль, хотя эта свобода выбора привела к большему количеству войн (как вооруженных, так и пламенных), чем что-либо еще.
Для некоторых непонятная причина, по которой string.Empty не является постоянной. Это означает, что в ряде случаев, когда требуется постоянная времени компиляции, string.Empty даже недопустим. Это включает блоки case "" в операторах switch, значения по умолчанию для необязательные параметры, параметры и свойства в применении атрибуты и множество других ситуаций (оставлено на усмотрение читателя). Поэтому, учитывая, что string.Empty запрещен в некоторых распространенных ситуациях, лучше использовать соглашение ""-везде.
Я также разрабатываю на Javascript, VBScript, SQL и VB6 ... и хотя string.Empty может работать только в .Net, "" (или '') работает везде. Мне нравится использовать "" просто для единообразия на разных языках в одном продукте.
В Visual Studio 2015 update 3 функция «Быстрые действия» редактора C# предлагает всегда «упрощать» String.Empty повсюду. когда я принимаю предложение, он преобразуется в string.Empty. Было бы интересно узнать причину этого.
У меня была проблема с пиаром, просившая меня заменить "" на string.Empty. Наверное, самый педантичный PR-выпуск.
Хотя разница очень-ОЧЕНЬ небольшая, разница все же есть.
1) "" создает объект, а String.Empty - нет. Но этот объект будет создан один раз и на него будет ссылаться из пула строк позже, если у вас есть еще один "" в коде.
2) Строка и строка одинаковы, но я бы рекомендовал использовать String.Empty (а также String.Format, String.Copy и т. д.), Поскольку точечная нотация указывает на класс, а не на оператор, и наличие класса, начинающегося с заглавной буквы, соответствует Стандарты кодирования C#.
string.Empty является "", проверьте источник
Я настоятельно предпочитаю String.Empty, помимо других причин, чтобы убедиться, что вы знаете, что это такое, и что вы случайно не удалили содержимое, но в первую очередь для интернационализации. Если я вижу строку в кавычках, мне всегда нужно задаться вопросом, новый ли это код и его следует поместить в таблицу строк. Поэтому каждый раз, когда код изменяется / проверяется, вам нужно искать «что-то в кавычках», и да, вы можете отфильтровать пустые строки, но я говорю людям, что это хорошая практика - никогда не помещать строки в кавычки, если вы не знаете, что это не будет локализовано. .
Практически каждый разработчик знает, что означает "". Я лично столкнулся с String.Empty в первый раз, и мне пришлось потратить некоторое время на поиск в Google, чтобы выяснить, действительно ли они являются то же самое.
Это общедоступное строковое поле, доступное только для чтения, и его значения: "" ... зачем это менять?
Вы упускаете то, о чем говорит @Jason. Как узнать, что вы впервые видите string.Empty? Знаете ли вы, что такое "", когда вы его впервые увидели?
На самом деле нет никакой разницы с точки зрения производительности и сгенерированного кода. При тестировании производительности они переходили туда и обратно, один из которых был быстрее другого, и только на миллисекунды.
Глядя на закулисный код, вы действительно не видите никакой разницы. Единственное отличие заключается в IL, в котором string.Empty использует код операции ldsfld.
а "" использует код операции ldstr, но это только потому, что string.Empty статичен, и обе инструкции выполняют одно и то же.
Если вы посмотрите на производимую сборку, она точно такая же.
Код C#
private void Test1()
{
string test1 = string.Empty;
string test11 = test1;
}
private void Test2()
{
string test2 = "";
string test22 = test2;
}
Кодекс IL
.method private hidebysig instance void
Test1() cil managed
{
// Code size 10 (0xa)
.maxstack 1
.locals init ([0] string test1,
[1] string test11)
IL_0000: nop
IL_0001: ldsfld string [mscorlib]System.String::Empty
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: stloc.1
IL_0009: ret
} // end of method Form1::Test1
.method private hidebysig instance void
Test2() cil managed
{
// Code size 10 (0xa)
.maxstack 1
.locals init ([0] string test2,
[1] string test22)
IL_0000: nop
IL_0001: ldstr ""
IL_0006: stloc.0
IL_0007: ldloc.0
IL_0008: stloc.1
IL_0009: ret
} // end of method Form1::Test2
Код сборки
string test1 = string.Empty;
0000003a mov eax,dword ptr ds:[022A102Ch]
0000003f mov dword ptr [ebp-40h],eax
string test11 = test1;
00000042 mov eax,dword ptr [ebp-40h]
00000045 mov dword ptr [ebp-44h],eax
string test2 = "";
0000003a mov eax,dword ptr ds:[022A202Ch]
00000040 mov dword ptr [ebp-40h],eax
string test22 = test2;
00000043 mov eax,dword ptr [ebp-40h]
00000046 mov dword ptr [ebp-44h],eax
@PrateekSaluja: чтобы увидеть IL, вы можете использовать ildasm.exe, который поставляется с Visual Studio. Чтобы увидеть разборку, используйте окно «Разборка» в меню отладки при достижении точки останова (работает и в коде выпуска).
Ненавижу, что я собираюсь рекомендовать этот продукт .. НО .. отражатель позволяет вам выбрать язык при разборке исходного кода, а IL - это вариант! ILDASM просто устарел ... Кажется, что команда MS tools не оттачивает или не выпускает хорошие инструменты!
Это полностью предпочтение стиля кода, то есть того, как .NET обрабатывает строки. Впрочем, вот мои мнения :)
Я всегда использую имена типов BCL при доступе к статическим методам, свойствам и полям: String.Empty или Int32.TryParse(...) или Double.Epsilon
Я всегда использую ключевые слова C# при объявлении новых экземпляров: int i = 0; или string foo = "bar";
Я редко использую необъявленные строковые литералы, поскольку мне нравится иметь возможность сканировать код, чтобы объединить их в многоразовые именованные константы. В любом случае компилятор заменяет константы литералами, так что это скорее способ избежать магических строк / чисел и придать им немного больше смысла с помощью имени. К тому же изменить значения проще.
Одно отличие состоит в том, что если вы используете синтаксис switch-case, вы не можете записать case string.Empty:, потому что это не константа. Вы получаете Compilation error : A constant value is expected
Посмотрите эту ссылку для получения дополнительной информации: строка-пустые-против-пустые-кавычки
Заявление switch - очень хороший пример. Кроме того, если вы сделаете необязательный параметр, например void MyMethod(string optional = "") { ... }, также невозможно будет использовать string.Empty. И затем, конечно, если вы хотите определить поле const или локальную переменную, const string myString = "";, снова "" - единственный вариант. Если бы только string.Empty был постоянным полем, не было бы разницы. Но это не так, поэтому в некоторых случаях вам придется использовать "". Так почему бы не использовать "" постоянно?
Это действительно сильный аргумент, потому что использование string.Empty не позволяет вам достичь последовательность в вашей кодовой базе: вы должны использовать две разные сущности, чтобы выразить одно и то же. И чтобы добавить к списку вещей, которые вы не можете делать: вы не можете использовать string.Empty с атрибуты.
Очень хорошие моменты! Ссылка не работает. Вот копия содержания: web.archive.org/web/20131230161806/http://kossovsky.net/…
На http://blogs.msdn.com/b/brada/archive/2003/04/22/49997.aspx:
As David implies, there difference between
String.Emptyand""are pretty small, but there is a difference.""actually creates an object, it will likely be pulled out of the string intern pool, but still... whileString.Emptycreates no object... so if you are really looking for ultimately in memory efficiency, I suggestString.Empty. However, you should keep in mind the difference is so trival you will like never see it in your code...
As forSystem.String.Emptyorstring.EmptyorString.Empty... my care level is low ;-)
Это сообщение в блоге MSDN было в 2003 году .... вы уверены, что это все еще верно для последних версий .NET ?!
@ CarstenSchütte: Мне кажется, что эта функция не предназначена для значительных изменений ... и если это так, то в Интернете было много шума по этому поводу.
@sergiol Если поле более эффективно, чем литерал, то это однозначно ошибка производительности. Так что есть надежда, что к настоящему времени это будет исправлено.
Никто не упомянул, что в VisualStudio строка имеет цветовую кодировку иначе, чем строка. Что важно для читабельности. Кроме того, нижний регистр обычно используется для переменных и типа, это не имеет большого значения, но String.Empty - это константа, а не переменная или тип.
String.Empty не является константой: см. stackoverflow.com/questions/507923/… Это фактически экземпляр класса String по дизайну. О раскраске упоминалось ранее, хотя и немного скрыто: stackoverflow.com/questions/263191/…
Я бы предпочел string.EmptyString.Empty, потому что вы можете использовать его без необходимости включать using System; в свой файл.
Что касается выбора "" вместо string.Empty, это личное предпочтение, которое должно решаться вашей командой.
Я единственный член команды, как мне решить? бросить кости?
Для тех, кому может быть интересно, как можно использовать константу string.Empty без импорта пространства имен using System - ключевые слова в C# просто преобразуются в свое полное имя, которое также включает пространство имен, прежде чем они будут записаны как MSIL в выходных * .dll или * .exe файл. Таким образом, string.Empty записывается компилятором как System.String.Empty в MSIL. И, как вы уже могли знать, если вы упомянули полностью определенное имя типа, вы можете пропустить импорт пространств имен в верхней части файла кода.
Эта тема довольно старая и длинная, так что извините, если такое поведение упоминалось где-то еще. (И укажите мне ответ, который охватывает это)
Я обнаружил разницу в поведении компилятора при использовании string.Empty или двойных кавычек. Разница проявляется, если вы не используете строковую переменную, инициализированную с помощью string.Empty или двойных кавычек.
В случае инициализации с помощью string.Empty появляется предупреждение компилятора.
CS0219 - The variable 'x' is assigned but its value is never used
никогда не испускается, в то время как в случае инициализации с двойными кавычками вы получите ожидаемое сообщение.
Это поведение объясняется в статье Connect по этой ссылке: https://connect.microsoft.com/VisualStudio/feedback/details/799810/c-warning-cs0219-not-reported-when-assign-non-constant-value
По сути, если я правильно понял, они хотят позволить программисту установить переменную с возвращаемым значением функции для целей отладки, не беспокоя его предупреждающим сообщением, и, таким образом, они ограничили предупреждение только в случае назначений стоимости и строки. Пусто - это не константа, а поле.
Я считаю, что вы первый, кто упомянул. Я прочитал эти вопросы и ответы несколько месяцев назад и не помню этой разницы, как если бы я упомянул ее.
Интересно. Обратите внимание, что объявление var unused = "literal"; может быть полностью оптимизировано (удалено) компилятором. Не может иметь побочных эффектов. С другой стороны, var unused = MyClass.Member; нельзя удалить полностью. Это потому, что чтение Member может иметь побочные эффекты. Если Member является статическим свойством с аксессором get, очевидно, что вызов геттера должен быть сохранен. Но даже если Member является статическим полем, может возникнуть побочный эффект, связанный с запуском статического конструктора. Конечно, было бы плохой стиль кодирования, если бы это было так. Но для чтения Member нужен манекен.
Я выполнил этот очень простой тест, используя следующий метод в консольном приложении:
private static void CompareStringConstants()
{
string str1 = "";
string str2 = string.Empty;
string str3 = String.Empty;
Console.WriteLine(object.ReferenceEquals(str1, str2)); //prints True
Console.WriteLine(object.ReferenceEquals(str2, str3)); //prints True
}
Это явно предполагает, что все три переменные, а именно str1, str2 и str3, хотя инициализируются с использованием разного синтаксиса, указывают на один и тот же строковый (нулевой длины) объект в памяти. Я выполнил этот тест в консольном приложении .NET 4.5. Так что внутренне у них нет никакой разницы, и все сводится к удобству того, какой из них вы хотите использовать в качестве программиста. Такое поведение строкового класса известно в .NET как интернирование струн. У Эрика Липперта есть очень хороший блог здесь, описывающий эту концепцию.
Я просто смотрел на какой-то код, и у меня в голове возник вопрос, который я прочитал некоторое время назад. Это, конечно, вопрос удобочитаемости.
Рассмотрим следующий код C# ...
(customer == null) ? "" : customer.Name
против
(customer == null) ? string.empty : customer.Name
Я лично считаю, что последнее менее двусмысленно и легче читается.
Как отмечали другие, фактические различия незначительны.
Я лично был свидетелем "", приводящего к (незначительным) проблемам дважды. Один раз произошла из-за ошибки младшего разработчика, плохо знакомого с командным программированием, а другой - из-за простой опечатки, но факт использования string.Empty позволил бы избежать обеих проблем.
Да, это в значительной степени вопрос суждения, но когда язык дает вам несколько способов сделать что-то, я склоняюсь к тому, который имеет наибольший контроль компилятора и наиболее строгое соблюдение во время компиляции. То есть нет "". Все дело в выражении конкретного намерения.
Если вы наберете string.EMpty или Strng.Empty, компилятор сообщит вам, что вы сделали это неправильно. Немедленно. Он просто не компилируется. Как разработчик вы ссылаетесь на намерение специфический, что компилятор (или другой разработчик) не может каким-либо образом неверно истолковать, и когда вы делаете это неправильно, вы не можете создать ошибку.
Если вы наберете "", когда имеете в виду "", или наоборот, компилятор с радостью сделает то, что вы ему сказали. Другой разработчик может или не сможет понять ваше конкретное намерение. Ошибка создана.
Задолго до string.Empty я использовал стандартную библиотеку, которая определяла константу EMPTY_STRING. Мы по-прежнему используем эту константу в операторах case, где string.Empty не допускается.
По возможности заставляйте компилятор работать на вас и исключите возможность человеческой ошибки, какой бы незначительной она ни была. ИМО, это превосходит «читабельность», как указывали другие.
Специфика и соблюдение времени компиляции. Это то, что на ужин.
Я использую "", потому что в моем коде он будет ярко-желтым ... по какой-то причине String.Empty полностью белый в моей теме Visual Studio Code. И я считаю, что это для меня самое главное.
Пустая строка похожа на пустой набор, просто имя, которое все используют для вызова "". Также в формальных языках строки, созданные из алфавита и имеющие нулевую длину, называются пустой строкой. И для набора, и для строки есть специальный символ. Пустая строка: ε и пустой набор: ∅. Если вы хотите поговорить об этой строке нулевой длины, вы назовете ее пустой строкой, чтобы все точно знали, о чем вы говорите. Теперь, если вы назовете это пустой строкой, почему бы не использовать string.Empty в коде, это показывает, что намерение явно выражено. Обратной стороной является то, что он не является константой и поэтому доступен не везде, как в атрибутах. (Это не постоянная величина по некоторым техническим причинам, см. Справочный источник.)
Возможно, это спорный комментарий, но в целом я считаю, что моя жизнь легче, когда я действую последовательно с Microsoft. Мы не можем знать полностью глубоко укоренившихся причин (иногда очень строгих, а иногда, я думаю, неуклюжих), по которым они что-то делают.
Они используют "" в автоматически сгенерированных файлах, таких как файл сборки, так что я этим и занимаюсь. Фактически, когда я пытаюсь заменить любой ниже "" на String.Empty, у меня происходит сбой Visual Studio. Вероятно, этому есть логическое объяснение, но с моими ограниченными знаниями, если я просто буду делать то, что делают они, большую часть времени все получается. (Contra: я знаю, что в некоторых автоматически сгенерированных файлах также используется String.Empty, что меня опровергает. :))
<Assembly: System.Reflection.AssemblyCulture("")>
<Assembly: System.Reflection.AssemblyDescription("")>
<Assembly: System.Reflection.AssemblyFileVersion("1.0.0.0")>
<Assembly: System.Reflection.AssemblyKeyFile("")>
<Assembly: System.Reflection.AssemblyProduct("")>
<Assembly: System.Reflection.AssemblyTitle("")>
См. Также это аналогичное обсуждение для java: stackoverflow.com/questions/213985/…