Question

What are the pros and cons of standardizing on using Option Compare Text vs Option Compare Binary for VB.NET development?

— EDIT —

Just some background since it seems like it would help – my development team has found it much easier to standardize on Option Strict On, Option Infer On, and Option Explicit due to their obvious advantages over the alternatives. What we haven’t found as easy to standardize on is Option Compare Text/Binary as there seem to be advantages and disadvantages to both and different developers have differing opinions. Some of the arguments for each side have been as follows:

Some of the advantages/arguments for Option Compare Text:

1. It reduces verbosity in the code by removing the need for StringComparers and .ToLower() calls and StringComparison.OrdinalIgnoreCase all over the place
2. Data needs are rarely concerned with casing, as evidenced by most databases being case-insensitive. Rarely would you ever really want to distinguish between THIS and This and this when doing a data comparison.
3. Certain specific use cases are simpler when you don’t have to worry about casing. For example, handling ASP.NET control events where commands are sent to the codebehind as strings and casing-issues are difficult to track down as the compiler cannot help you. Think Select Case statements for <asp:repeater> events as an example.
4. Many of the concerns raised about text comparison concern internationalization, which is often not that relevant to a lot of applications.
5. VB specifically is case insensitive as a language, though Visual Studio helps you by at least enforcing consistency in your casing. SQL is case insensitive as well. Strings are the only place where you have to remember to worry about it, which highlights the awkwardness in ways you wouldn’t normally notice it if you were worried about it everywhere.

Some of the advantages/arguments for Option Compare Binary:

1. C# works this way, as do most other languages. It’s somewhat unexpected to have alternate behavior and the unexpected is not good in programming.
2. There is a slight performance penalty with Option Compare Text as evidenced by the IL generated on compile. Option Compare Binary doesn’t have that penalty.
3. Option Compare Text only makes certain parts of string handling case insensitive. But, it doesn’t make it so that things like dictionary indexing are case insensitive by default. So, it’s not like Option Compare Text actually makes it so that you don’t have to worry about casing at all. If it only works half way, why bother?
4. Programming is hard. It’s best not to attempt to smooth over that fact. Worrying about string casing is part of the deal. Humans recognize THIS is different from This and tHiS. Of course your code should too – after all, they aren’t really the exact same string.

So I’m really just wondering if there are any other considerations.

— EDIT 2 —

Perhaps it would help if I defined what I’d consider an answer to this. If you can point to any authoritative external resource that talks through these issues more thoroughly, or point to a standards and best practices discussion or book that gives guidance on this topic, that would certainly count.

Answer 1

With Option Compare Text you don’t need to worry about case when comparing strings. That can be a big benefit, and avoid converting everything to lower ( or upper) case to comapre for string equality.

The other place where this plays a part is sorting of strings. Option Compare Text will sort like the file list in Windows, but Option Compare Binary will sort like a Unix file list (all the upper case file names appear before the lower-case file names).

Update

After reading the comments and the other answer, and thinking a bit more, I’d say Option Compare Binary is the way to go from point of view of consistency with the rest of the .Net Framework. If dictionary keys etc. are case-sensitive regardless of the Option Compare setting then using binary comparisons by default throughout your code is just being consistent. All you then need to worry about is if, for a particular comparison, you need it to be case-insensitive and code for that.

If you go with Option Compare Text then not only do you need to worry about whether or not you need a particular comparison to be case-(in)sensitive you also need to be aware of the default behaviour in the current context.

It then becomes an argument not of consitency with other languages, but of consistency with the framework you’re developing to.