What is the purpose of case sensitivity in languages? [duplicate]_问答_开发者

This question already has answers here: Closed 12 years ago.

Possible Duplicates:
Is there any advantage of being a case-sensitive programming language?
Why are many languages case sensitive?

Something I have always wondered, is开发者_如何学JAVA why are languages designed to be case sensitive?

My pea brain can't fathom any possible reason why it is helpful.

But I'm sure there is one out there. And before anyone says it, having a variable called dog and Dog differentiated by case sensitivity is really really bad practise, right?

Any comments appreciated, along with perhaps any history on the matter! I'm insensitive about case sensitivity generally, but sensitive about sensitivity around case sensitivity so let's keep all answers and comments civil!

It's not necessarily bad practice to have two members which are only differentiated by case, in languages which support it. For example, here's a fairly common bit of C#:

private readonly string name;
public string Name { get { return name; } }

Personally I'm quite happy with case sensitivity - particularly as it allows code like the above, where the member variable and property follow conventions anyway, avoiding confusion.

Note that case-sensitivity has a culture aspect too... not all cultures will deem the same characters to be equivalent...

One of the biggest reasons for case-sensitivity in programming languages is readability. Things that mean the same should also look the same.

I found the following interesting example by M. Sandin in a related discussion:

I used to believe case sensitivity was a mistake, until I did this in the case insensitive language PL/SQL (syntax now entierly forgotten):
function IsValidUserLogin(user:string, password :string):bool begin
   result = select * from USERS
            where USER_NAME=user and PASSWORD=password;
   return not is_empty(result);
end
This passed unnoticed for several months on a low-volume production system, and no harm came of it. But it is a nasty bug, sprung from case insensitivity, coding conventions, and the way humans read code. The lesson for me was that: Things that are the same should look the same.

Can you see the problem immediately? I couldn't...

I like case sensitivity in order to differentiate between class and instance.

Form form = new Form();

If you can't do that, you end up with variables called myForm or form1 or f, which are not as clean and descriptive as plain old form.

Case sensitivity also means that you don't have references to form, FORM and Form which all mean the same thing. I find it difficult to read such code. I find it much easier to scan code where all references to the same variable look exactly the same.

Something I have always wondered, is why are languages designed to be case sensitive?

Ultimately, it's because it is easier to correctly implement a case-sensitive comparison correctly; you just compare bytes/characters without any conversions. You can also do other things like hashing really easy.

Why is this an issue? Well, case-insensitivity is rather hard to add unless you're in a tiny domain of supported characters (notably, US-ASCII). Case conversion rules vary by locale (the Turkish rules are not the same as those in the rest of the world) and there's no guarantee that flipping a single bit will do the right thing, or that it is always the same bit and under the same preconditions. (IIRC, there's some really complex rules in some language for throwing away diacritics when converting vowels to upper case, and reintroducing them when converting to lower case. I forget exactly what the details are.)

If you're case sensitive, you just ignore all that; it's just simpler. (Mind you, you still ought to pay attention to UNICODE normalization forms, but that's another story and it applies whatever case rules you're using.)

Imagine you have an object called dog, which has a method called Bark(). Also you have defined a class called Dog, which has a static method called Bark(). You write dog.Bark(). So what's it going to do? Call the object's method or the static method from the class? (in a language where :: doesn't exist)

I'm sure originally it was a performance consideration. Converting a string to upper or lower case for caseless comparison isn't an expensive operation exactly, but it's not free either, and on old systems it may have added complexity that the systems of the day weren't ready to handle.

And now, of course, languages like to be compatible with each other (VB for example can't distinguish between C# classes or functions that differ only in case), people are used to naming things the same text but with different cases (See Jon Skeet's answer - I do that a lot), and the value of caseless languages wasn't really enough to outweigh these two.

The reason you can't understand why case-sensitivity is a good idea, is because it is not. It is just one of the weird quirks of C (like 0-based arrays) that now seem "normal" because so many languages copied what C did.

C uses case-sensitivity in indentifiers, but from a language design perspective that was a weird choice. Most languages that were designed from scratch (with no consideration given to being "like C" in any way) were made case-insensitive. This includes Fortran, Cobol, Lisp, and almost the entire Algol family of languages (Pascal, Modula-2, Oberon, Ada, etc.)

Scripting languages are a mixed bag. Many were made case-sensitive because the Unix filesystem was case-sensitive and they had to interact sensibly with it. C kind of grew up organically in the Unix environment, and probably picked up the case-sensitive philosophy from there.

Case-sensitive comparison is (from a naive point of view that ignores canonical equivalence) trivial (simply compare code points), but case-insensitive comparison is not well defined and extremely complex in all cases, and the rules are impossible to remember. Implementing it is possible, but will inadvertedly lead to unexpected and surprising behavior. BTW, some languages like Fortran and Basic have always been case-insensitive.