Лучший способ разбить длинные строки в исходном коде C#

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

Это делается во время компиляции. Это в точности эквивалентно "string1string2string3".

Предположим, у вас есть:

string x = "string1string2string3"
string y = "string1" + "string2" + "string3"

Компилятор выполнит соответствующее интернирование, так что x и y относятся к одним и тем же объектам.

Обновлено: В ответах и ​​комментариях много говорится о StringBuilder. Многие разработчики, кажется, считают, что конкатенация строк должна выполняться всегда с помощью StringBuilder. Это чрезмерное обобщение - стоит понять почему StringBuilder хорош в одних ситуациях, а в других нет.

Разве вы не можете использовать StringBuilder?

Ваш пример будет объединен во время компиляции. Все строковые строковые и константные строковые переменные объединяются во время компиляции.

Следует иметь в виду, что включение любых строк только для чтения приведет к задержке конкатенации до времени выполнения. string.Empty и Environment.NewLine являются строковыми переменными только для чтения.

это действительно зависит от того, что вам нужно. Как правило, если вам нужно объединить строки, наилучшая производительность во время выполнения будет достигнута при использовании StringBuilder. Если вы ссылаетесь в исходном коде на что-то вроде var str = "String1" + "String2", оно будет преобразовано в строку str = "String1String2" при компиляции. В этом случае у вас нет накладных расходов на конкатенацию

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

string query = @"SELECT whatever
FROM tableName
WHERE column = 1";

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

StringBuilder - хороший способ пойти, если у вас много (более четырех) строки для объединения. Это быстрее.

Использование String.Concat в приведенном выше примере выполняется во время компиляции. Поскольку это буквальные строки, они оптимизируются компилятором.

Однако если вы используете переменные:

string a = "string1";
string b = "string2";
string c = a + b;

Это делается во время выполнения.

StringBuilder будет вашим самым быстрым подходом, если вы используете любое количество строк.

http://dotnetperls.com/Content/StringBuilder-1.aspx

Если вы просто набираете несколько строк (5 или меньше - хорошее правило), скорость не будет иметь значения, какой тип конкатенации вы используете.

Есть какой-нибудь способ сделать это. Я предпочитаю использовать строковые методы из C#. Первый образец:

строка s = string.Format ("{0} {1} {0}", "Привет", "Автор"); результат s = "Привет, привет";

Как насчет следующего метод расширения (который вдохновлен методом общих тегов одна линия) ...

using System;
using System.Text.RegularExpressions;
using static System.Text.RegularExpressions.RegexOptions;

namespace My.Name.Space
{
    public static class StringHelper
    {
        public static string AsOneLine(this string text, string separator = " ")
        {
            return new Regex(@"(?:\n(?:\s*))+").Replace(text, separator).Trim();
        }
    }
}

... в сочетании с дословный строковый литерал, используемым как таковой:

var mySingleLineText = @"
    If we wish to count lines of code, we should not regard them
    as 'lines produced' but as 'lines spent'.
".AsOneLine();

Обратите внимание, что пробелы «внутри» строки остаются неизменными, например:

// foo      bar hello        world.
var mySingleLineText = @"
    foo      bar
    hello        world.
".AsOneLine();

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

// foobar
var mySingleLineText = @"
    foo
    bar
".AsOneLine("");

Пожалуйста, обрати внимание: Эта форма конкатенации строк выполняется во время выполнения из-за задействованного вспомогательного метода (в отличие от конкатенации через оператор +, выполняемой во время компиляции, как также указано в принятом ответе). Так что, если производительность является проблемой, выбирайте +. Если вы имеете дело с длинными фразами и удобочитаемостью и в центре внимания «простота использования», то подход, предложенный выше, возможно, стоит рассмотреть.