GetOffMyCase!

One of those tired old arguments you see crop up again and again among programmers is that of case sensitivity in programming languages. The general trend currently seems to be that most are advocating a move towards case insensitive languages. These people tend to call case sensitivity a legacy of the “old” days. They then go on to cite that modern compilers have long been able to save us from the case sensitive buggy-man. Perversely the popularity of case sensitive languages seems to be rising while popularity of case insensitive ones is falling... and no, I have no empirical evidence of this, just something that seems true based on my own observations over many years in the field.

The arguments against case sensitivity range a bit, but one common complaint is that mistakes in case cause hard to detect errors or lead to having two different functions whose name differs only in capitalization. Another common complaint is that comparing strings or working with things that are strings in case sensitive languages often leads to bad behavior, especially when dealing with file paths or URLs where the underlying platform is not case sensitive but the language itself is.

Look, I’ll grant a couple of things:

• Scripting languages or any language that makes heavy use of late binding should avoid being case sensitive. JavaScript in particular would be a LOT better if it were not case sensitive. In fact, JavaScript is what I like to call a case-destructive language.
   
• String comparisons in ANY language should, by default, use case insensitive comparisons unless explicitly told otherwise. Most languages provide a mechanism to perform case sensitive or insensitive comparisons, but most C based languages default to doing a case sensitive match. Even C# (my language of choice) is guilty of this.

While there are a couple of points these advocates make that I can agree with, I disagree overall that case insensitivity is “better”. In case sensitive languages, after a little exposure, the use of case becomes a useful tool on its own.

Once you understand the conventions of the language you can usually tell a LOT about what is going on in code just by observing which case is being used.

For example, Identifiers in C# are camel cased when they are local variables, private fields or method parameters.  Pascal case is used for public members, class names, etc. The use of Case to distinguish meaning in C# is generally very consistent from one developer to another. The adherence to good naming conventions is partially due to the case sensitivity of the language itself, and is not a work around in spite of case sensitivity.

When I see something called myName in C# I KNOW I’m dealing with a local variable or private member. When I see MyName I know I’m dealing with a public member.

This is NOT confusing to me or most C# developers. On the contrary, it is  quite elegant and we get used to noticing the case of identifiers, and the case used tells us instantly something useful about the code.

But when I deal with VB code, I have to play guessing games when I see myName1 and myName2. Sure, conventions help some there too, but the conventions always feel like sloppy workarounds where the sole purpose is to support case insensitivity.

Of course, most of this relies on a decent understanding of the conventions of the language and the programmer being competent enough to follow those conventions. I’ve been working in C# for many years and I’ve never had serious problems with case induced errors. Sure, occasionally I have made a case related error, but I can’t say that this happens more often than the mistakes I’ve made in VB due to inconsistent and awkward naming. In both languages those kinds of mistakes usually get caught by the compiler or the IDE quickly.

Case sensitive languages have another side effect though, and in my mind this is THE most important thing. Case sensitivity makes programmers pay attention to detail. This may seem like a very simple thing, but attention to details is THE skill that I’ve discovered marks the difference between a decent programmer and a great one.