There can be too much of a good thing you know! Last night as I was scanning through some code, I noticed that all the String APIs were used in the culture safe overloads so thoughtfully provided by .NET. As I silently thanked FxCop for codifying this, I also came to the conclusion that I can safely bid goodbye to all intl bugs in that code.
After a quick run though, I noticed some of the sorting orders in the UI were wrong! Ouch! OrdinalIgnoreCase was the harmless looking deceiver. In a bid to stick to the .NET guidance rules the code was relentlessly smattered with OrdinalIgnoreCase all around. Hence, no matter what the current culture was, the sorts and compares all gave the same result each time.
Ok – another explanation. There are 2 kinds of data – input and output. Say, your input data is taken in and used for processing. When you want to compare your input data with some benchmark variables defined, you will want to use our favourite OrdinalIgnoreCase in the comparison. This is purely a non linguistic comparison. In cases where you want case sensitivity to be maintained, then you can use Ordinal in the compare API. Consider a case where you want to extract the contents of a project file. Project file names are unique and case insensitive. Hence, when comparing between your user input and the project file name, you can use the OrdinalIgnoreCase in your comparison and expect it to yield accurate results.
In cases where you would like to do a linguistic comparison, where the current culture does matter to you, use the CurrentCulture value in the StringComparison object. For instance, if you would like to create a sorted list of random user input values, you must use the CurrentCulture value. In the Turkish culture I is sorted before i whereas in the English culture i is sorted before I. But if I sort using the Ordinal value, I’ll get a standard order that the values will appear in, no matter what the culture of the client is. But that is not what we want! Hence, your comparisons need to take the current culture into account. Usually the output data needs to be presented in the culture that is being used by the user while input data when being processed must be culture insensitive.
That brings us back to the original topic – using OrdinalIgnoreCase in ALL cases will not rid your code of intl bugs!