覆盖 ToString() 以进行调试和记录 - 字符串应该本地化吗? [英] Overriding ToString() for debugging and logs - should the string be localized?

问题描述

我正在设计一个 .NET 库，其他开发人员将使用该库来制作 Web 和桌面应用程序.我在各种类中覆盖 ToString() 以提供用于调试目的和包含在应用程序日志文件中的信息.

I'm designing a .NET library that will be used by other developers making both web and desktop applications. I'm overriding ToString() in various classes to provide information for debugging purposes and for inclusion in application log files.

我的一些课程包含数字和日期.

Some of my classes contain numbers and dates.

考虑一个对象，它包含一个名为 date 的 DateTime 和一个名为 value 的 double(可能还有其他字段)以及)...如果我覆盖该对象的 ToString()，我可能想要执行以下操作:

Consider an object that contains a DateTime called date and a double called value (and maybe other fields as well)... If I override that object's ToString(), I might want to do something like:

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

但这将包括来自 date.ToString() 和 value.ToString() 的结果，这将给我根据 Thread 本地化的字符串.CurrentThread.CurrentCulture.

But that will include the result from date.ToString() and value.ToString(), which will give me strings that are localized according to Thread.CurrentThread.CurrentCulture.

在我看来，这似乎是错误的.我的 ToString() 实现返回的字符串用于调试和记录消息，而不是用于用户界面.所以我认为返回本地化的字符串只会混淆问题.如果2,341"出现在日志文件中，开发人员需要知道线程的 CurrentCulture 的值，才能知道它是 2000 341 还是 2 点 341.日期更容易混淆——一个字符串像 xx/xx/xxxx 可以是 dd/mm/yyyy 或 mm/dd/yyyy.我不希望我的 ToString() 方法产生这种歧义.

And that, to me, seems wrong. The strings returned by my ToString() implementations are meant for debugging and log messages, not for user interfaces. So I think returning localized strings could only confuse matters. If "2,341" appears in log files, a developer would need to know the value of the thread's CurrentCulture to know whether it meant 2 thousand 341 or 2 point 341. It's even more confusing with dates - a string like xx/xx/xxxx could be dd/mm/yyyy or mm/dd/yyyy. I don't want my ToString() methods to create that sort of ambiguity.

所以我倾向于让我的 ToString() 方法对文化不敏感，以确保所有返回的字符串在不同文化中都是一致的.例如，在内部，我的 ToString() 方法会像 value.ToString(CultureInfo.InvariantCulture) 那样格式化数字.

So my inclination is to make my ToString() methods culture-insensitive, to ensure that all returned strings are consistent across cultures. For example, internally my ToString() methods would do like value.ToString(CultureInfo.InvariantCulture) to format a number.

然而，.NET 库中的规范似乎是在默认的无参数 ToString() 实现中使用 CurrentCulture.许多具有 ToString() 方法的对象也具有 ToString(IFormatProvider) 方法.就好像 .NET 的设计者决定 ToString() 的默认用途应该是用于用户界面显示(本地化)，以及调试和日志(您需要调用 ToString()code>ToString(CultureInfo.InvariantCulture)) 是次要的.

However, the norm in .NET libraries seems to be to use CurrentCulture in default no-args ToString() implementations. Many objects that have a ToString() method also have a ToString(IFormatProvider) method as well. It's as if the designers of .NET decided that the default use of ToString() should be for user-interface display (localized), and that debugging and logs (for which you'd need to call ToString(CultureInfo.InvariantCulture)) are secondary.

因此，如果我以一种对文化不敏感的方式实现我的 ToString() 方法，我觉得我会有点违背常规.但默认情况下创建区分文化的字符串似乎很愚蠢，因为文化敏感性对于日志文件或调试没有意义.

So if I implement my ToString() methods in a culture-insensitive way, I feel I'd be going against the grain somewhat. But it seems silly to create culture-sensitive strings by default, when culture-sensitivity makes no sense for log files or debugging.

我可以使用 CurrentCulture 在默认的 ToString() 实现中表示数字和日期，并且还提供 ToString(FormatProvider) 方法这样人们就可以获得一个不区分文化的字符串用于日志文件等.但这似乎很愚蠢，因为它只是迫使开发人员编写更多代码来获取我猜他们会想要的不区分文化的字符串(无论他们是有没有考虑过).

I could use the CurrentCulture to represent numbers and dates in my default ToString() implementations, and also provide ToString(FormatProvider) methods so that people can get a culture-insensitive string for use in log files etc. But that seems dumb as it's just forcing developers to write more code to get the culture-insensitive string that I'm guessing they'll want (whether they've considered it or not).

最重要的是，像 ObjectName[value=12.234, date=2011-10-01] 这样的字符串不应该出现在用户界面中，所以程序员为什么会想要它本地化?

The bottom line is that a string like ObjectName[value=12.234, date=2011-10-01] shouldn't ever appear in a user interface, so why would a programmer ever want it to be localized?

我一直在阅读框架设计指南中关于实现 ToString() 的建议.有些建议似乎有些矛盾.例如:

I've been reading the advice in Framework Design Guidelines on implementing ToString(). Some of the advice seems somewhat contradictory. For example:

我认为 ToString 是为 UI 通用类型提供的一种特别危险的方法，因为它可能在实现时考虑了某些特定的 UI，使其无法用于其他 UI 需求.为了避免以这种方式诱惑自己，我更愿意让我的 ToString 输出尽可能令人讨厌，以强调唯一应该看到输出的人类"是开发人类"(他们所有的亚种)自己的).

I consider ToString an especially dangerous method to provide for UI-generic types, because it's likely to be implemented with some specific UI in mind, making it useless for other UI needs. To avoid tempting myself in this way, I prefer to make my ToString output as geeky as possible to emphasize that the only "humans" that should ever see the output are "developer humans" (a subspecies all their own).

和

ToString 最重要的值是调试器使用它作为显示对象的默认方式.

The most important value of ToString is that the debugger uses it as the default way of displaying the object.

似乎不太适合:

DO 返回文化相关信息时基于当前线程文化的字符串格式.

DO string formatting based on the current thread culture when returning culture-dependent information.

和

使用线程的 CurrentCulture 属性返回的 CultureInfo 实例来格式化任何数字或日期

use the CultureInfo instance returned by a thread's CurrentCulture property to format any numeric or date

我完全支持遵循这些准则，并编写符合程序员期望的 API.但是如果 ToString() 是给程序员用的，那么本地化它似乎很愚蠢.C# 编译器不会让程序员使用依赖于系统的十进制分隔符来编写双精度文字，那么为程序员编写的 ToString() 方法肯定应该表现得相似吗?

I'm all for following the guidelines, and writing APIs that do what programmers expect. But if ToString() is for programmers, then it seems silly to localize it. The C# compiler won't let a programmer write a double literal using a system-dependent decimal separator, so surely ToString() methods written for programmers should behave similarly?

你怎么看?当 ToString() 的输出不用于用户界面时，其中的数字和日期是否应该本地化?>

What do you think? When the output from ToString() is not intended for use in a user-interface, should the numbers and dates within it be localized or not?

更新

我使用 DebuggerDisplay 属性做了一些测试，看起来，默认情况下，它以不区分区域性的方式格式化数字.

I did some tests using the DebuggerDisplay attribute, and it looks like, by default, it formats numbers in a culture-insensitive way.

[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();
}

在调试器中运行该测试，当它中断时，您可以看到 DoubleHolder 中包含的 double 被格式化为 . 作为小数点分隔符.

Run that test in the debugger and, when it breaks you can see that the double contained in DoubleHolder is formatted with a . as a decimal separator.

然后关闭 Visual Studio，将标准和格式的 Windows 区域选项更改为法语，然后再次运行测试.你会看到 doubleString 有一个 , 作为十进制分隔符，但调试器仍然在 DoubleHolder 中显示 doublecode> 带有 .

Then close Visual Studio, change your windows Regional Options for Standards and Formats to French, say, and run the test again. You'll see that doubleString has a , as the decimal separator, but the the debugger still shows the double in DoubleHolder with a .

我希望在适当的法语版 Windows 上使用法语版 Visual Studio 进行测试.在 Visual Studio 中，如果您转到工具 -> 选项 -> 环境 -> 国际设置，您可以将语言设置为与 Microsoft Windows 相同".我的安装默认设置为英语".但是要获得法语版的 Visual Studio，您需要有法语版的 Windows，而我的 Windows 版本似乎只有英语版.如果有人有法语 Windows 或任何其他使用 , 作为小数点分隔符的语言环境，如果您能检查调试器是否使用 . 或 , 作为格式化双精度中的小数点分隔符.

I would have liked to test this on a proper French version of Windows, with Visual Studio in French. In Visual Studio, if you go to Tools -> Options -> Environment -> International Settings, you can set the Language to "Same as Microsoft Windows". By default on my installation it was set to "English". But to get Visual Studio in French you need to have Windows in French, and my version of Windows seems to be English only. If anyone has a French Windows, or any other locale that uses , as a decimal separator, it'd be great if you could just check whether the debugger uses . or , as the decimal separator in formatted doubles.

我想知道 Thread.CurrentThread.CurrentUICulture 是否会对 Visual Studio 调试器的显示方式产生影响，而且我不确定像上面那样的设置是否相同完全用法语运行 Visual Studio.

I'm wondering if Thread.CurrentThread.CurrentUICulture might make a difference to how the Visual Studio debugger shows things, and I'm not sure that setting it like I do above would be the same as running Visual Studio completely in French.

但从上面看来，调试器确实始终使用 . 作为小数点分隔符.这对我来说意味着独立于文化的 ToString() 方法很好，可能更可取，如果它用于调试目的.

But from the above it does look like the debugger consistently uses . as the decimal separator. This implies to me that a culture-independent ToString() method is fine, probably preferable, if it's intended for debugging purposes.

推荐答案

对于调试，您需要查看 调试器显示属性，不使用ToString().

For debugging you want to look into Debugger Display Attributes, not use ToString().

[DebuggerDisplay("{Name} [date={Date}, value={Value}]")]
public class MyClass {
    // ...
}

关于ToString()的本地化，有机会再评论.

As for localization of ToString(), I will pass on the opportunity to comment.

这篇关于覆盖 ToString() 以进行调试和记录 - 字符串应该本地化吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！