Case Sensitive Software is EVIL

In my article Breaking Backwards Compatibility is EVIL I voiced my disapproval of the idea of introducing case sensitivity for function names into PHP when version 6 is released. This would mean that a function name with the same spelling but different case would be treated as a completely different function. PHP already has case-sensitive variable names (yuck!), and some of the core developers want to extend it for no other reason than to be "consistent" with other languages. This is such a controversial topic that I decided to split it off as a separate article.

As far as I am concerned the introduction of case-sensitivity into software (operating systems, compilers and tools) was the worst ever decision in the entire history of computing. Personally I blame the authors of Unix as they not only created an operating system which was illogical, unintuitive and user-unfriendly, but they also were either too stupid or too lazy to create a case-insensitive file system. All the existing computer systems were case-insensitive, so what was the justification for the change? To make matters worse this caused every piece of software written to run on a Unix system to also be case-sensitive, and so this stupid mistake has spread like a plague.

In the past 30 years I have worked on a variety of mainframe, mini-computer and micro-computer (PC) systems, and none of these has been case-sensitive in any way - this includes the operating systems, compilers, text and document editors, and database query tools. The authors of this software saw no need for case-sensitivity, and none of the users ever requested it, so where did this stupid idea come from?

The Windows operating system, the most widely used OS in the world today, is not sensitive to case, and neither is any tool or application which runs on it. Does this cause any problems? I think not. Would it cause any problems if this software were to decide that case was important? You betcha!

Can you name me one single problem where introducing case-sensitivity was the solution? On the other hand I have lost count of the situations where having case-sensitivity was actually the cause of the problem, so the idea of implementing something which causes problems instead of solving them strikes me as being incredibly stupid. If you think that case-sensitivity is important, can you answer the following questions:

1. Is any computer language issued with a set of function names in different combinations of upper and lower case, such as readfile(), readFile(), ReadFile() and READFILE(), where each combination of case means something different?
2. Is any computer language issued with a set of variable names in different combinations of upper and lower case, such as box, Box and BOX, where each combination of case means something different?
3. If this feature were available would you encourage or discourage its use?
4. If you would discourage the use of this feature as (presumably) it would lead to code which was difficult to maintain, would it not make sense to remove it from the language so that it could not be used even by accident?
5. A change in case does not change the meaning of a word in spoken language (just check any dictionary to see if the same word has different entries for upper and lower case) so why should it be any different in a computer language?

If constructs such as GOTO are removed from modern languages due to their propensity to produce spaghetti code, then why include a feature that can help produce an even worse mess? Some languages which have case-sensitivity (such as Visual Basic) avoid any such problems by automatically changing the case of any variable or function names as they are keyed in to whatever has been previously declared, thus making the fact that the are case-sensitive totally invisible. While this can work with languages which are statically typed and compiled (such as VB), it is more difficult to implement in those which are dynamically typed and interpreted (such as PHP).

Some of the arguments I have heard in favour of case-sensitivity are pretty weak:

• It is the standard in all languages and tools.
  • It may exist in all the languages and tools that you have used, but it has never existed in any of the languages and tools that I have used. That includes those available on mainframe computers in the 1970s, mini-computers in the 1980s, and personal computers in the 1990s. If you have only worked on Unix-based systems then your experience is quite limited.
  • It is not the 'standard' it is merely 'common practice'. Standards are supposed to represent 'best practice', not 'common practice', and considering the problems that it can cause you will never convince me that case-sensitivity is 'best' under any circumstances. Just because "shit happens" doesn't make "shit" the standard. An idea is not supposed to be implemented unless it is a good idea. Implementing a bad idea just to be consistent with other languages simply perpetuates a consistently bad idea.
• Case can sometimes make a long variable name more readable.
  • Just because a variable name like avariablelikethisisveryhardtounderstand is less readable than itsMuchEasierToSayThingsWithSomeCapitals is no excuse. Personally I prefer the use of underscores to those awful camelcaps, as in an_underscore_is_far_better_than_those_stupid_camelcaps.
• Case insensitivity can lead to inconsistent code.
  • One of the arguments against case insensitivity is that a programmer could write multiple references to the same constant or variable in different case, thus being "inconsistent". As well as writing thisisaspecialfunction() he may even write THISISASPECIALFUNCTION(), or, god forbid, tHiSiSaSpEcIaLfUnCtIoN().

    While I agree that the mixing of case in such a manner would be a stupid thing to do, I should also point out that although it is inconsistent it most certainly does NOT cause any problems in a case insensitive language because the language disregards case and treats all those variations as the same function. This inconsistency, while being a feeble point to argue, does not confuse the language therefore no actual harm is done.

  • The same cannot be said for case sensitive languages where it would be possible to deliberately define different functions with the same spelling but different combinations of case. So when somebody else reads the code he may spot the inconsistent use of case, but will he realise that each variation actually refers to a totally different function? How many problems could this cause, and how long would it take to debug? Thus this situation in case sensitive languages could lead to obfuscated and unmaintainable code, while in case insensitive languages it would have no effect whatsoever.
• Switching from one case to another can be confusing.
  • Although the misuse of case insensitivity may be inelegant and may offend the sensibilities of a fussy programmer, the misuse of case sensitivity can be far more serious in that it can lead to bugs which are difficult to track down. You may see a variable name or function name that you recognise, but if you don't notice the slight change in case you won't realise that you are actually dealing with a different object. Now how confusing would that be?
  • Seeing a familiar term written in different case in case insensitive software may be inconsistent, but it is not confusing. Seeing a familiar term written in different case in case sensitive software without realising that each slight change in case has made a completely different term can be far more than confusing - it can lead to bugs that are hard to track down. If a programmer does not have the ability to deal with changes in case which do NOT cause bugs, then how do you expect that same programmer to deal with those changes in case which DO cause bugs?
  • If the computer can read code in different case without any problem, and humans can read code in different case without any problem, then what exactly is the problem? If there is no problem then why is there a need for a solution?
• Different case has different meanings in some computer languages.
  • Some computer languages do not use the addition of symbols to differentiate between constants, variables, functions and methods, and this causes confusion amongst some programmers who cannot tell the difference between foo the constant, foo the variable and foo the function. To circumvent this "difficulty" those programmers have created conventions whereby the use of upper and lower case can help identify what each token actually is. These are individual preferences, not language rules, yet these same programmers, when they move to another language, want to bring their old conventions with them. What is worse they want to change what were originally a set of personal choices into a set of requirements that everyone else must follow. What is their justification? "To be consistent", or "To have the same standards in all languages".
  • Other programmers in other languages do not have any such difficulty, therefore the use of different case does not provide any benefits. Take, for example, good old COBOL where it is possible to have a variable and a function with the same name, as in:

    move 'text' to foobar
    call foobar using ... giving ...
    

    It is quite obvious from the context when foobar is a variable and when it is a function. I do not need to use different combinations of case to tell the difference, nor does the compiler, so the use of different case does not provide any benefits whatsoever.

    Other languages, like PHP, use different symbols to identify different tokens, as in:

    foo - a constant
    $foo - a variable
    foo() - a function
    $object->foo() - a class method
    $object->foo - a class property
    

    There are five occurrences of the token foo which are all different, yet neither the programmer nor the compiler need special combinations of upper and lower case to tell the difference. As far as I am concerned if the language itself does not need differences in case to tell the difference between one type of token and another, then neither should any programmer. If anyone feels compelled to use variations in case in such a manner then all they are doing is highlighting a deficiency in themselves.
• Computer languages are different from human languages.
  • They are not as different as you would seem to think. They are both used for communication - one for human-to-human communication, and the other for human-to-computer communication. They both have to be readable by humans and they both have common origins. That is why early computer languages such as COBOL were based around subjects, verbs, predicates, sentences and paragraphs.
  • Critics try to tell me that slight changes in case in spoken language can change the meaning of a sentence. I was given the example "This is a china cup" and "I am going to China" where the word "CHINA" has a different meaning because of the case in which it is written. While it is true that a word can have more than one meaning, it is not case which changes the meaning, it is context. The two sentences "this is a china cup" and "THIS IS A CHINA CUP" mean exactly the same thing even though the case is completely different. If you have a single container you could call it box, Box or BOX. It doesn't matter because they each mean the same thing. But if you have several containers it is common sense to use names such as box1 and box2, or perhaps box_in and box_out. It is common practice to use different names for different objects, not the same name with different case. Only someone who is intellectually challenged would use box and Box to mean different containers.
• Case-sensitivity exists in popular languages, therefore it must be popular.
  • There is a difference between 'widely-used' and 'popular' or 'favourite'. Just because a language is used by a lot of programmers does not mean that it's their favourite language. Often they have to use a particular language because their employer tells them to. Not many programmers can actually earn a living with their 'favourite' language.
  • It does not mean that every feature of that language is better than the equivalent feature in rival languages. I have worked with many programmers who have worked with more than one language, and I have never met anyone who liked all of the features of one language over another. There was always some feature in one which they preferred over another, and different programmers would always pick a different set of features, and for different reasons.
  • Some languages which are considered to be "case sensitive" are actually nothing of the sort - they are "case preserving". They prevent the same function or variable from being defined in a different case, so duplicates are not allowed to exist with different case. All references are automatically adjusted to match the case used in the original definition, so everything appears to be in the same case.
• Case-sensitivity doubles the number of options that can be available with a single-character parameters.
  • Just because this makes command -b different from command -B does not necessarily make it a good idea. The benefits of allowing case-sensitivity in one area should have been weighed against the contra-benefits in other areas. The authors of this idea obviously did not consider the wide-ranging ramifications of their decision.
  • The argument that the use of 52 single-character parameters is more efficient that 26 is another one of those stupid fallacies. Writing efficient code has absolutely nothing to do with the number of keystrokes that are needed to achieve a result. The code must execute as efficiently as possible, but it must also be readable to the developers who have to maintain it. If a single-character parameter is used instead of a proper word then the reader may have to spend precious time in looking up what that character actually means, whereas if a proper word is used no such lookup is required. Thus the time 'saved' in typing a single character is expended many times over with each different reader causing this 'saving' to produce a net loss.

The fact that some languages and tools have case-sensitivity is no excuse for insisting that ALL languages and tools be changed to implement case-sensitivity "just to be consistent". Ideas are supposed to be implemented because they are good ideas, because they provide benefits or solve problems. Implementing a bad idea just to be consistent with other languages simply perpetuates a consistently bad idea.

Some of my critics like to argue that "plenty of modern languages are case sensitive, yet nobody complains about any problems they cause". But what they fail to notice is that most of these languages trap the situation where a variable or function is declared or referenced with the same spelling but a different case and are able to deal with it before it can cause any problems. This is what happens in Visual Basic for example:

• If you try to define a function or variable that has already been defined, the Visual Basic IDE will automatically change the case of the previous definition to match the case of your current definition, thus ensuring that they are duplicates of the same definition and not different definitions. When you try to compile the source code you will get an error which points out the duplicate names.
• When you enter a reference to a function or variable the Visual Basic IDE will search for the definition with that spelling and automatically convert the case of the reference to the case of the definition so that they match exactly.

So even though Visual Basic is case sensitive it does not allow the same name (i.e. with the same spelling) to exist more than once with different combinations of upper and lower case. Thus the functions readfile(), readFile() and ReadFile() are exactly the same, and the variables somedata, someData and SomeData are exactly the same. The VB IDE automatically corrects any variation in case, so the use of different case does not cause any problems. How many other languages shield the unwary programmer from differences in case in the same way? THAT is why programmers never complain about case sensitivity causing problems, for the simple reason that any problems which COULD be caused are automatically detected and corrected by the IDE or notified at the time of compilation. It is just not possible to create a compiled VB program which contains the same spelling but with different case even though the language is (apparently) sensitive to case.

Where a language does NOT provide this auto-correction facility, thus deliberately allowing the same name with different case to refer to different objects, this can lead to situations which are a maintenance nightmare.

• If a programmer accidentally defines a function or variable with the same spelling but different case this is treated as a completely different entity. Is it good practice to allow readfile(), readFile() and ReadFile() to exist as different functions? Is it good practice to allow somedata, someData and SomeData to exist as different variables?
• If a programmer accidentally references a variable with the same spelling but different case this will generate an error at runtime (E_NOTICE in the case of PHP). If the installation's error reporting is too low this type of error could be difficult to track down.
• If a programmer accidentally references a function with the same spelling but different case this will generate an error at runtime (E_FATAL in the case of PHP).
• If a programmer deliberately litters his code with duplicate functions and variables (i.e. where the spelling is the same but only the case is different), would this be considered as good practice or deserving of a good talking-to?
• It is considered to be good practice to identify functions and variables with meaningful names, but it is the spelling of such names which carries the meaning, not the case in which it is written.

The reason that few programmers complain about the problems caused by case sensitive software is that their complaints are instantly rejected. "It's the standard" they are told, "so you must learn to live with it". Few programmers have the audacity to question such stupid practices, but I am not so timid. I have had my share of being forced to work with second-rate standards which were full of half-baked ideas, and I know what a joy it is to work with first-rate standards where every statement is properly explained and justified. Statements which cannot be explained or justified have no place in any standards, and I'm afraid that explanations such as "it's the standard", or "it's consistent" or "because I say so" just don't qualify.

How many languages or libraries come supplied with functions and variables which exist more than once but with different case? The answer is NONE! Why not? Because it is not considered to be good practice. It would cause immense amounts of confusion and maintenance headaches. So, if this language "feature" is avoided by all language authors and competent programmers because of its potential for misuse, then why do these languages allow this "feature" to exist in the first place? If the GOTO statement has been eliminated from many languages due to the problems which can be caused by its misuse, then why not remove case-sensitivity for exactly the same reason? After all, this would be "consistent" and "promote good practice".

Traditional naming conventions state that all functions and variables should be given names that are meaningful and descriptive - a function name should describe what it does, and a variable name should describe what it contains. This means that if you want a different function or a different variable then you create a different name with different spelling and therefore a different meaning, not the same name in a different case. Am I really the only person to see this?

Those who say that the correct use of naming conventions avoids any problems with case sensitivity are missing the point - it does not solve the problem, it merely hides it. It simply papers over the crack, but the crack is still there and waiting to catch the unwary. It does not prevent programmers from using what is supposed to be the "wrong" case, either accidentally or deliberately. If you have ever debugged a program where the problem was caused by the incorrect use of case you will know what a ridiculous problem this is. Doing this accidentally is excusable, but some perverse programmers do it deliberately just to cause confusion, to create obfuscated code which only they can maintain. In my opinion if the accidental or deliberate use of the wrong case can cause such problems then the ability to use the wrong case should be removed from the language. The re-introduction of case insensitive software, or at least case preserving software, even if it were limited to variable names and function names, would eliminate such annoying problems without any downside whatsoever.

As far as I am concerned if a computer language does not care which case a token is written in then neither should any programmer. If a programmer cannot look at code and understand how that code will be processed by the computer then he is, quite frankly, in the wrong profession. Every programmer is exposed to mixtures of upper and lower case in the outside world before he becomes a programmer, so anyone who cannot understand source code which is written in a mixture of upper and lower case is, quite frankly, in the wrong profession.

There are some people who try to justify the use of case sensitive software with spurious reasons:

1. They say it is more efficient because it doesn't have to try all possible combinations of case when it performs a token lookup, such as when processing an HTML or XML document. Why don't these people use a simple trick that I came across decades ago? When a file is first read into memory just convert all the tokens to lowercase, then all lookups need be done only once in lowercase.
2. They say it is necessary in some languages because they have characters which exist in lower case only and do not have an equivalent in upper case. This just shows that their thinking is deficient - instead of saying that such a character does not exist in upper case they should instead say that such a character does not exist in a different form in upper case. So every character will exist in both lower and upper case, but in some circumstances both characters will be the same.
3. They say that it is necessary in some languages as trying to convert all tokens in upper- or lower-case for comparisons is not possible as there is a one-to-any relationship instead of the normal one-to-one relationship. The prime example given is the lowercase German character ß which for a long time was represented as SS in uppercase. Although typographers in Germany created and used a single uppercase equivalent ẞ as far back as 1905, it was not formally adopted until 2017.

Have you also given thought to the time when keyboards give way to voice-controlled input? How cumbersome will it be not just to say the word but to spell out the case of every single letter? Do you think your audience will congratulate you for your foresight and wisdom? I don't think so.

So remember, when you say that you are in favour of case sensitive software you are also saying that you are in favour of the following:

• The ability to create different variable names with the same spelling but different case.
• The ability to create different function names with the same spelling but different case.
• The ability to create different class properties with the same spelling but different case.
• The ability to create different class methods with the same spelling but different case.

Am I really the only one who thinks that these are NOT good ideas? Apparent not. Please take a look at the following:

• The Case For Case Insensitivity from codinghorror.com
• The Case for Case-Preserving, Case-Insensitivity from somethinkodd.com
• Is it case-sensitive? by Scott Hanselman
• Why is there still case sensitivity in some programming languages? from stackexchange.com
• Case-sensitivity is the past trolling us from tsotech.com
• Why are many languages case sensitive?

I think that the article somethinkodd.com sums up the argument quite nicely:

There is no longer any excuse for making humans learn and handle the quirks of the way computers store upper- and lower-case characters. Instead, software should handle the quirks of human language.

References

• Breaking Backwards Compatibility is EVIL
• Software Patents are EVIL
• Stored Procedures are EVIL
• Object Relational Mappers are EVIL
• Dependency Injection is EVIL
• Not-so-SOLID OO Principles
• Singletons are NOT evil
• Getters and Setters are EVIL
• Object Interfaces are EVIL
• Object Associations are EVIL
• Inheritance is NOT evil
• I fail to GRASP these principles
• Namespaces are for numpties
• The case against static typing in PHP
• The case against overloading in PHP

Amendment History