<\/p>\n
It is a mistake to consider the prime characteristic of high-level languages to be that they allow us to express programs merely in their shortest possible form and in terms of letters, words, and mathematical symbols instead of coded numbers. Instead, the language is to provide a framework of abstractions and structures that are appropriately adapted to our mental habits, capabilities, and limitations.<\/em> – Niklaus Wirth<\/a> [Ref]<\/a><\/p><\/blockquote>\n
Introduction<\/h2>\n
Okay, now that I’ve got the framework for my argument in place, I am ready to start in earnest.<\/p>\n
We have reviewed what case sensitivity<\/a> is, and what the options are. How should we decide which one to use?<\/p>\n
I think that case-preserving, case-insensitivity<\/em> is, almost always, the optimal behaviour. This may be somewhat controversial, so let me explain my position.<\/p>\n
Addressing the Arguments Against<\/h2>\n
I’ll start by addressing the reasons against<\/em> case-insensitivity – that is, for<\/em> case-sensitivity<\/em>.<\/p>\n
Simplicity of Development<\/h3>\n
One argument for<\/em> case-sensitivity<\/em>, in internationalised software, is that it neatly side-steps all the clumsiness and complexity<\/a> of dealing with case issues in multiple characters sets and locales. It makes the programmer’s job a lot easier by not trying to find the corresponding upper- (or lower-) case character from the user’s input.<\/p>\n
It is also slightly more efficient, with less effort (both computational and development) spent on processing the characters.<\/p>\n
I can understand this argument, and I have a certain amount of sympathy for the programmer who is trying to support internationalisation of their software – I’ve been there myself.<\/p>\n
However, this argument, to me, sounds too similar to the “elegance and efficiency” argument about Reverse Polish Notation that I described before<\/a>. Making things slightly easier for the programmer, at a cost of ignoring the capabilities of the user, is a short-term solution. <\/p>\n
Perhaps during the initial development of Unix in the 1970s, the extra effort involved in finding a canonical form of a filename – even in ASCII, rather than Unicode – was too slow, but this is no longer an adequate argument.<\/p>\n
Conciseness of Identifiers<\/h3>\n
Another argument for<\/em> case-sensitivity<\/em> is that it makes it possible to use the same word as two different identifiers. A common example is to let an instance be named after a class, but with different case. <\/p>\n
e.g.
class Foo foo(\"bar\");<\/code><\/p>\nWhile I will admit to having often adopted such a coding style in C++, I find it very hard to defend this practice.<\/p>\n
We have seen before<\/a> that similar sounding variable names in the same scope is deplorable, and the opportunity for confusion here is enormous. The gap between the concepts of an instance and the class is greater than a simple case-shift of the initial letter might indicate. The reason<\/em> for the existence of the instance should be included in the identifier.<\/p>\n
Yes, that may mean typing in a few more characters per identifier. Some programmers seem to find that abhorrently inefficient. I don’t share such views. The time taken to add a few more characters aids the readability of the code. Wirth’s quote describes my position well.<\/p>\n
Addressing the Arguments For<\/h2>\n
Wirth asks for software to be adapted to our “mental habits, capabilities, and limitations”. When we examine these properties, as it comes to case, we can see that English-speaking humans treat upper- and lower-case to be both very similar, and yet slightly different. This similarity suggests that the software cannot afford to be case-sensitive. This difference suggests that non-case preservation will hinder understanding.<\/p>\n
Upper- and Lower-Case are the same…<\/h3>\n
The capabilities and limitations of English speaking humans include getting easily confused between two strings that are very similar to our language-processing brains – even where they are clearly different to a character-encoding-processing machine.<\/p>\n