何时应指定 CurrentCulture 或 InvariantCulture，何时应不指定？
指定 CurrentCulture 或 InvariantCulture 而根本不指定区域性的最佳实践是什么？
据我所知，例如，如果您正在进行序列化，则需要 InvariantCulture 作为指定数据值的规范表示的方法。这在基于区域性的字符串操作中只占相对较小的比例。
我发现它又长又冗长，而且大多数时候每次我指定它时都很难看，比如：
var greeting = string.Format(CultureInfo.CurrentCulture, "Hello ", userName);
然而，我的团队最近打开了 FxCop，现在有人在推动在任何地方都使用 CultureInfo。结合简洁性、可读性和功能性的最佳技术是什么？
一些不错的阅读材料：
What is the best practice for specifying CurrentCulture or InvariantCulture and not specifying the culture at all?
From what I have read, if you're doing serialization, for instance, you need InvariantCulture as a means of specifying a canonical representation of a data value. That's a relatively small percentage of culture-based string manipulations.
I find it long, verbose, and ugly most of the time to specify it every time I do, say:
var greeting = string.Format(CultureInfo.CurrentCulture, "Hello ", userName);
However, my team recently turned FxCop on and now there's a push to always use CultureInfo EVERYWHERE. What is the best technique to combine brevity, readability, and functionality?
Some good reading material:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里有一个固有的权衡。
至少，每当您在程序内部执行任何操作时，您都需要指定 CultureInfo 使用 InvariantCulture。例如，将其与序列化一起使用会强制数据表示始终相同，因此您不必担心内部数据格式的国际化问题。
话虽这么说，在任何地方指定它都有一些优点 - 主要是迫使您确保正确处理它。内部程序工作与 UI 工作需要指定不同的文化（前提是您想要正确本地化您的应用程序）。因此，复杂的程序往往要求在任何地方都指定它，因为保留“默认”充其量是危险的，并且随着时间的推移往往会引入错误。
然而，正如您所注意到的，指定这一点往往会增加代码的大小，并可能降低可读性。这导致了权衡：通过更短的代码实现可读性和可维护性，与通过在任何地方都更加明确来实现适当的国际化和本地化和可维护性进行权衡。
在我看来，这里没有“正确”的答案 - 这实际上取决于您的应用程序。如果您的应用程序完全与演示有关，并且不进行大量数据操作，尤其是不使用任何类型的自我管理文件存储，那么设置当前区域性（和 ui 区域性）一次可能就可以了。然而，我发现更复杂的应用程序往往无法以这种方式正常工作，在这种情况下，FxCop 在各处指定这一点的建议似乎更有吸引力。
There is an inherent trade-off in play here.
At a minimum, you'll want to specify CultureInfo to use InvariantCulture whenever you are doing anything internal within your program. For example, using this with Serialization forces the data representation to always be the same, so you don't have to worry about internationalization issues with your internal data formats.
That being said, specifying this everywhere has some advantages - mainly in terms of forcing you to make sure you're handling this correctly. Internal program work vs. UI work needs to have a different culture specified (provided you want to properly localize your application). As a result, a complex program tends to require this to be specified everywhere, as leaving the "default" is dangerous at best, and tends to introduce bugs over time.
However, specifying this, as you noticed, tends to increase the size of your code, and potentially reduce the readability. This leads to the trade-off - readability and maintainability via shorter code vs. proper internationalization and localization and maintainability via being more explicit everywhere.
In my opinion, there is no "right" answer here - it really depends on your application. If your application is completely about presentation, and not doing a lot of data manipulation, especially not with any type of self-managed file storage, setting the current culture (and ui culture) once may be fine. I've found that more complicated applications tend to not work as well in this fashion, however, in which case the FxCop suggestions of specifying this everywhere seem more attractive.
默认值已经是 Windows 初始化的当前区域性。因此，明确使用 CultureInfo.CurrentCulture 只是浪费时间。任何合适的序列化格式（包括二进制序列化和 XML 序列化）都将以文化不变的方式序列化 DateTime。
使用非默认文化是非常危险的。线程将始终以 Windows 指定的默认区域性启动，并由用户在安装 Windows 时配置。 .NET 始终启动线程池线程，您将面临在该线程中获得与主线程不同的文化的风险。这可能会导致各种微妙的问题。就像有一个 SortedList 突然不再排序一样。
The default is already the current culture as initialized by Windows. So using CultureInfo.CurrentCulture explicitly is just a waste of time. Any decent serialization format (including binary serialization and XML serialization) will serialize a DateTime in a culture invariant way.
Using a culture that is not the default is very dangerous. A thread will always be started with the default culture as specified by Windows and configured by the user when she installed Windows. .NET starts threadpool threads all the time and you'll risk getting a culture in that thread that is different from your main thread. Which can cause all manner of subtle problems. Like having a SortedList that suddenly isn't sorted anymore.