Переопределение ToString () для отладки и журналов - следует ли локализовать строку?

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

Некоторые из моих классов содержат числа и даты.

Рассмотрим объект, который содержит DateTime с именем date и double с именем значение (а также, возможно, другие поля). .. Если я переопределю этот объект ToString () , я могу сделать что-то вроде:

public override string ToString() {
    return "ObjectName[date=" + date + ", value=" + value + "]";
}

Но это будет включать результат из date.ToString () и value.ToString () , который даст мне строки, локализованные в соответствии с Thread.CurrentThread.CurrentCulture .

И это мне кажется неправильным. Строки, возвращаемые моими реализациями ToString () , предназначены для отладки и сообщений журнала, а не для пользовательских интерфейсов. Поэтому я думаю, что возврат локализованных строк может только запутать ситуацию. Если в файлах журнала отображается «2341», разработчику необходимо знать значение CurrentCulture потока, чтобы знать, означало ли оно 2 тысячи 341 или 2 пункта 341. С датами это еще более сбивает с толку - строка вроде xx / xx / xxxx может быть дд / мм / гггг или мм / дд / гггг. Я не хочу, чтобы мои методы ToString () создавали такую ​​двусмысленность.

Поэтому я склоняюсь к тому, чтобы мои методы ToString () не зависели от языка и региональных параметров, чтобы гарантировать, что все возвращаемые строки согласованы в разных культурах. Например, внутренние мои методы ToString () будут работать как value.ToString (CultureInfo.InvariantCulture) для форматирования числа.

Однако нормой в библиотеках .NET, похоже, является использование CurrentCulture в реализациях по умолчанию без аргументов ToString () . Многие объекты, у которых есть метод ToString () , также имеют метод ToString (IFormatProvider) . Это как если бы разработчики .NET решили, что использование по умолчанию ToString () должно быть для отображения пользовательского интерфейса (локализовано), а также для отладки и журналов (для которых вам нужно будет вызвать ] ToString (CultureInfo.InvariantCulture) ) являются вторичными.

Поэтому, если я реализую свои методы ToString () нечувствительным к культуре способом, я чувствую, что буду несколько идти против течения. Но кажется глупым создавать строки, чувствительные к культуре по умолчанию, когда чувствительность к культуре не имеет смысла для файлов журнала или отладки.

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

Суть в том, что строка вида ObjectName [value = 12.234, date = 2011-10-01] никогда не должен появляться в пользовательском интерфейсе, так зачем программисту когда-либо хотеть его локализовать?

Я читал советы в Руководстве по дизайну фреймворка на реализация ToString () . Некоторые советы кажутся несколько противоречивыми. Например:

Я считаю ToString особенно опасным методом предоставления универсальных типов пользовательского интерфейса,потому что он, вероятно, будет реализован с учетом определенного пользовательского интерфейса, что сделает его бесполезным для других нужд пользовательского интерфейса. Чтобы не соблазнять себя подобным образом, я предпочитаю делать свой вывод ToString как можно более вызывающим, чтобы подчеркнуть, что единственные «люди», которые когда-либо должны видеть вывод, - это «люди-разработчики» (отдельный подвид ).

и

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

, похоже, не вписывается в:

DO форматирование строки на основе текущего языка и региональных параметров потока при возврате информации, зависящей от языка и региональных параметров.

и

используют экземпляр CultureInfo , возвращаемый свойством потока CurrentCulture , для форматирования любого числа или даты

Я полностью за соблюдение рекомендаций и написание API делают то, чего ожидают программисты. Но если ToString () предназначен для программистов, то локализовывать его кажется глупым. Компилятор C # не позволит программисту написать двойной литерал, используя системно-зависимый десятичный разделитель, поэтому, конечно же, методы ToString () , написанные для программистов, должны вести себя аналогичным образом?

Как вы думаете? Если вывод ToString () не , предназначенный для использования в пользовательском интерфейсе, должны ли числа и даты в нем быть локализованы или нет?

Обновить

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

[DebuggerDisplay("[value={value}]")]
class DoubleHolder {
    private double value;
    DoubleHolder(double value) {
        this.value = value;
    }
}

[TestMethod]
public void TestDebuggerValue() {
    DoubleHolder s = new DoubleHolder(12345678.12345);
    string doubleString = TestDouble.ToString();
    CultureInfo current = Thread.CurrentThread.CurrentCulture;
    Thread.CurrentThread.CurrentUICulture = current;
    CultureInfo ui = Thread.CurrentThread.CurrentUICulture;
    Debugger.Break();
}

Запустите этот тест в отладчике, и, когда он прервется, вы увидите, что double , содержащийся в DoubleHolder , отформатирован с помощью . как десятичный разделитель.

Затем закройте Visual Studio, измените региональные параметры Windows для стандартов и форматов, скажем, на французский, и снова запустите тест. Вы увидите, что doubleString имеет , в качестве десятичного разделителя, но отладчик по-прежнему показывает double в DoubleHolder с .

Я хотел бы протестировать это на правильной французской версии Windows с Visual Studio на французском языке. В Visual Studio, если вы перейдете в Инструменты -> Параметры -> Среда -> Международные настройки, вы можете установить для языка значение «Такой же, как в Microsoft Windows». По умолчанию при моей установке он был установлен на «английский». Но чтобы получить Visual Studio на французском языке, вам необходимо иметь Windows на французском языке, а моя версия Windows кажется только английской. Если у кого-то есть французская Windows или любая другая локаль, которая использует , в качестве десятичного разделителя, было бы здорово, если бы вы могли просто проверить, использует ли отладчик . или , в качестве десятичного разделителя в форматированных числах с двойной точностью.

Мне интересно, может ли Thread.CurrentThread.CurrentUICulture повлиять на то, как отладчик Visual Studio показывает вещи, и я не уверен, что установка его, как я сделал выше, будет таким же, как работает Visual Studio полностью на французском языке.

Но из вышесказанного похоже, что отладчик постоянно использует . как десятичный разделитель. Для меня это означает, что независимый от культуры метод ToString () - это нормально, возможно, предпочтительнее, если он предназначен для целей отладки.