Is it simply a matter of inheritance? C++ was case-sensitive because C was, Java is case-sensitive because C++ is, etc? Or is there a more pragmatic reason behind it?

+50  A: 

I don't think you'll get a better answer than "because the author(s) of that language thought it was better that way". Personally, I think they're right. I'd hate to find these lines anywhere in the same source file (and refer to the same object+method)...


I don't think anyone would be happy to see this...

Paulius Maruška
+1 For a case in point, just look at the sleaze caused by case insentitivity of MS-Windows file systems.
+1 it's all about readability
In fairness, have case-sensitivity doesn't prevent that monstrosity from occurring, it simply guarantees that all four will be calls to different methods on different objects. I don't know that that's a good thing, either. :)
Adam Bellaire
Case insensitive languages don't have these problems as any serious IDE will fix the case for you. Anyway if you are working in Notepad you can fix the case with a simple Search and Replace, you can't do that in a case sensitive language as it risks breaking the code.
damn, that is cool :) i will start using it.
I agree that would suck. However, it would suck far worse if I found that and they all referred to *different* combos of object and method.
i dOnT KNoW iT doEsN't SeEm sO bAd ToO mE?
@Adam - at least the compiler will flag three out of those four as errors and force you to correct them (as long as you don't go and make them methods for gods sake).
Erik Forbes
-1 "I'd hate to find these lines anywhere in the same source file". Leave it at that --
Tom A
See my answer to this question. It is bad practice to use names that differ only by case.
Tom A
Only thing worse than different versions of SOMEOBJECT.SOMEMETHOD() varying only in case referring to same object/method pair is them referring to different object/method pairs
+23  A: 

My guess would be that case sensitivity enlarges the name space. A nice trick such as

MyClass myClass;

would be impossible with case-insensitive compiler.

thats why i like it
Matt Briggs
It would be possible if types and variables didn't share a namespace, 'though.
Joachim Sauer
It wouldn't be impossible: the compiler could use the position of each token, to know which is the name of a type and which is the name of a variable.
@ChrisW - and then some perverse genius would write "myCalss myClass" - wouldn't they? And you'd get stuck maintaining that.
And your syntax highlighting code editor would colorfully highlight the difference.
@recursive: and that glorious technicolor will not help you when you do text search or replace.
sure it will!, are you using a 30-year old editor or something? :-)
Java, for example, will indeed let you have variables and classes with the same name: String String = "String"; is perfectly valid.
Mike Houston
@Mike Houston: It is? OMG. OK, more reasons to avoid Java :)
@puetzk: And :SRChooseHiGrp! to you too.
Q: Why did Wirth choose case sensitivity for Modula-2 even though his earlier Pascal had been case-insensitive. A: He discovered he needed more than 26 variables in one program. Yes... it's a joke, but there's a kernel of truth there.
+15  A: 

Back when parsing and compiling was real expensive and would take all night it was advantageous to the compiler if it didn't have to worry about case.

Once indentifiers came in to existance that were only unique via there case it became very difficult to go back. Many developers liked it and there doesn't seem to be a big desire to undo it.

I agree, this is all about performance.
At least one who mentioned the technical aspect.
Don't you think its the other way around? In the day when parsing was expensive converting everything to upper or lower case took to long. Therefore you had to be very specific and variable 'Foo' and 'foo' where not considered the same variable...
@Luke: I think you've mistunderstood me. By making the _language_ case-sensitive the compiler doesn't have to worry about case since 'Foo' and 'foo' are not the same identifier. The compilier can simply use the binrary representations of the identifiers.
+28  A: 

It's actually extremely practical, both for the developer and for the language syntax specification: lower/upper case distinction adds a great deal of expressiveness to identifier naming.

From the point of view of the language syntax, you can force certain identifiers to start with a lower or upper case (for instance Java class name). That makes parsing easier, and hence helps keeping the syntax clean.

From a developer point of view, this allows for a vast number of convenient coding conventions, making your code clearer and easier to understand.

Axelle Ziegler
Although the Java language doesn't enforce any case rules in the syntax.
Adrian Pronk
I stand corrected, some conventions are so widespread I was convinced they were actually part of the syntax.
Axelle Ziegler
Eclipse will at least give you a warning if you don't use the style-guide case conventions for classes.
Mike Houston
This particular coding convention, identifiers that differ by case alone, makes code *harder* to read. See my answer to this question.
Tom A
+9  A: 

Case sensitivity adds to language readability by the use of naming conventions. You can't write

Person person = new Person("Bill");

if your language is case insensitive, because the compiler wouldn't be able to distinguish between the Class name and the variable name.

Also, having Person, person, PersoN, PeRsOn, and PERSON, all be equivalent tokens would give me a headache. :)

Bill the Lizard
person as person("Bill")
Robert Gould
I worked on a maintenance program written in ADA when I first got out of college. Most of the code was WRITTEN LIKE THIS with all kinds of other random casing stuck in. I had a headache everyday from reading it.
Disagree strongly. Having worked with both kinds of languages extensively, having to worry about casing differences in identifiers makes reading unfamiliar code far harder in case-sensitive languages.
Depends on syntax. It wouldn't work in Python, but if you have sigils or multiple namespaces or something else to distinguish them, it works just fine. I see ((list list)) in Common Lisp all the time.
+29  A: 

One interesting thing to consider is that English is also case-sensitive. (I suspect this is true for most natural languages, but it may well not be true for all.)

There's a big difference (where I live, anyway, near the town of Reading) between:

I like reading.


I like Reading.

Similarly, while many people do capitalise incorrectly, and you can usually understand what is meant, that doesn't mean such writing is considered correct. I'm a stickler when it comes to this kind of thing, which is not to say I get everything right myself, of course. I don't know whether that's part of the inheritance of programming language case sensitivity, but I suspect it may be.

One distinct advantage of case sensitivity for programming languages is that the text becomes culturally insensitive as well. It's bad enough having to occasionally spell out to a compiler which text encoding is used for a source file - having to specify which culture it's in would be even worse :(

Jon Skeet
Well Japanese, Korean and Chinese don't have case, and it doesn't affect legibility. But your point is value.
Robert Gould
Arabic also doesn't have case. Lower case is a rather recent invention, about 1000 years old.
Interesting. So is the different between upper and lower case Greek letters a purely modern thing too? I was pretty sure that Latin only used upper case letters, but didn't want to say for certain without checking it out.
Jon Skeet
in .NET world you say "I Like Reading" :P
Erik Forbes
+16  A: 

Case folding is only simple in English (and for all characters < 128). The German sz or "sharp s" (ß) doesn't have an upper case variant in the ISO 8859-1 charset. It only received one in Unicode after about a decade of discussion (and now, all fonts must be updated...). Kanji and Hiragana (Japanese alphabets) don't even know lower case.

To avoid this mess, even in this age of Unicode, it is not wise to allow case folding and unicode identifiers.

Aaron Digulla
+1. The biggest headache I can imagine is with internationalization.
Matt Ball
+4  A: 

How do you yell if you dont HAVE CAPS! AHHH!

Have to be expressive. But in all honesty, of all the people in the world, those who work with programming logic would be the first to insist that differences are in fact differences.

+2  A: 

Lots of people here have said that it would be bad for several forms of capitalization to refer to the same thing, e.g.:


What would be really bad is if these all referred to different objects in code. If you've got variables person, perSoN and PERSON all referring to different things, you've got a problem.

Rudd Zwolinski
By typical coding standards, Person would be a class, person a variable name, and PERSON a constant. It's often useful to use the same word with different capitalization to mean something related but slightly different.
Bill the Lizard
Bill, there is nothing anywhere enforcing that, so I am constatly comming across code that behaves differently. If you can't count on it, then you have to assume it could be anything and go look it up. This is why case-sensitivity is a hazard.
+2  A: 

Case sensitivity doesn't really help case consistency.


In a case insensitive language that can be fixed automatically by the editor easily. In a case sensitive language fixing it it's harder as it may be legal. The editor first has to ckeck if foo.Bar and fOO.bAR exist and also has to guess that you typed with the wrong case rather than forgetting to declare the variable (as Foo is different to fOO).

+1  A: 

Because many people find employeeSocailSecurityNumber just as readable as employee_social_security_number and it is shorter.

Jim C

Not an answer - I agree in part with Aaron Digulla and also like having consistency mandatory - but a couple of examples why this isn't to do with disambiguating values and types.

Both Java and Common Lisp have separate namespaces for variables and classes, so neither of these snippets are ambiguous. One language is case sensitive, the other isn't. The Java syntax defines where a type or a variable is expected, so it is not ambiguous to having the same identifier with different bindings in the class and value (and for that matter package) namespaces. Symbols in Common Lisp are effectively insensitive to case (being interned as uppercase by default), and doesn't use syntatic clues to differentiate types and values. Instead it uses different resolution operators to resolve the symbol 'Person in the value or class namespaces.


public class Person {
    public static void main (String...args) {
        Person Person = new Person("Bill");


    Person (String Name) { 
        this.Name = Name;

    String getName () { return Name; }

Common Lisp:

> (defclass person () ((name :accessor person-name :initarg :name)))
> (setf person (make-instance 'person :name "bob"))
#<PERSON #x00033465FC40>
> pErSon
#<PERSON #x00033465FC40>
> (equal "bob" (person-name PERSON))
> (find-class 'PERSON)
Pete Kirkham
Common Lisp is case sensitive - it's also case-folding. The reader will uppercase things you type.
David Thornley
True. Edited to say 'effectively case insensitive', as symbols are interned to uppercase unless you specifically tell them not to be.
Pete Kirkham
in Java if you define a variable with the same name as a class you can no longer access the class for calling its static methods; your variable shadows the class name. For classes in the root package this could be a problem.
Mr. Shiny and New
This is mostly right, but one part is a tad misleading: you say "Symbols [are] interned as uppercase by default". In fact, they're *read* as uppercase; even uninterned symbols are upcased: '#:foo => #:FOO
+3  A: 

Because they're as dumb as a box of frogs, for precisely the reasons given for the opposite viewpoint in this thread (I'm not even gonna ask what that's about. Wood for the trees and all that).

When FOOBAR = FooBar = foobar, you get to choose your convention, and other coders can do the same whether they share your preference or not. No confusion.

They also can't get away with the stroke of genius that is having a constant, function and variable all with the same name in the same file, albeit with different caps. Again, no confusion.

You call your variable WebSite, they call theirs Website, and which system gets confused? Not an easy catch either, when you're scanning.

As for lookups, is it really that much more processing to convert the name to lowercase before looking it up? Doing your own premature optimisation is one thing, expecting it from the developer of your language of choice is a whole other level of missing the point.

...and yet, all these answers saying case-sensitivity reduces confusion. Sigh

Consider a class Color, a function Label::Color (which queries the label's color) and a member variable Label::color (which stores the current color). I find this convention more readable _and_ writable than calling the accessor "GetColor" and the variable "m_color". What do you think?
Having woked in case-insensitive languages a lot Iraim, I think both suck, and I don't ever do either (even in case-sensitive languages). Both are just crutches so you don't have to actually think about what truly makes those things different.
Iraimbilanja: I think you're not Japanese. :-)
+5  A: 

Many (non-programming) languages (e.g. European using the Roman alphabet) are case-sensitive, so it's natural for native speakers of those languages to use upper- / lower-case distinctions.

The very idea that programming languages wouldn't be case-sensitive is a historical artifact arising from the limitations of early-generation hardware (including pre-computer teletype machines that used a 5-bit character code).

People who argue for case-blind languages must be unable to distinguish




(It's a joke! ;-)

Case sensitive natural languages? tell that 2 the txting teen8rs
Most(non-programming) languages are not dual-case languages. In fact, only Europe and USA has dual-case languages.
Varun Mahajan
With one minor distinction (below) I take your point that dual-case writing is not universal across natural languages. However, much early work in computer programming was done in Europe and the US, so it's no surprise that the writing conventions there tended to show up in programming languages. (Dual-case vs mono-case is a property of a writing system, not a language. Some languages have more than one written form, and some of those include a form using the Roman alphabet with mixed case. Of course, some of those are non-indigenous.)
+28  A: 


UNIX was case sensitive and so the first programming languages were case sensitive.

Computers are not forgiving - an uppercase character is not the same thing as a lowercase character, they're entirely different. And back when processing cycles, RAM and so forth were expensive it wasn't seen as worth the effort to force compilers and computers to be "forgiving", people were just trying to get the things to work.

Notice how case insensitivity didn't really become something useful until things like VB came along - once companies started to get invested in the concept that getting the masses to program was a good thing for their bottom line (i.e., Microsoft makes more money if there's more programs on Windows) did the languages start to be friendlier and more forgiving.

Voted up. This is in fact, *the* answer.
UNIX was case sensitive for the same reasons early languages were case sensitive not because of. Programming languages pre-date UNIX, obviously.
I think you're a bit wrong. Originally, everything was in uppercase (FORTRAN, COBOL, LISP, etc.). But it was hard to read, so they added case insensitivity to some systems (IBM mainframe), and case sensitivity to some other (Unix). The system case-sensitivity then determines language case-sensitivity. But originally, the languages were case insensitive, but you had to use uppercase.
+2  A: 

There's also Common Lisp, which is a case-sensitive language that many people mistakenly believe is case-insensitive. When you type (car x) into the Listener, it turns into (CAR X) for processing. It is possible to define symbols with lower-case names, but they have to be quoted with something like |lower-case-symbol|. Therefore, typing in (car x) or (CAR X) or (Car X) all works the same.

(Franz Lisp was at one point introducing what they called "modern" capitalization, in which the Listener would not fold cases, and CL keywords would be in lowercase. I never followed it well enough to know what happened there.)

David Thornley
upvoted note because it precisely answered the question but was entertaining and informative
Andy Dent
The reader can do whatever you want: setf readtable-case to :upcase, :downcase, :preserve, or :invert. But the builtins are all uppercase, and people don't tend to like saying (CAR my-list).
Thanks for the clarification, Ken. I neglected to mention that I was referring to default settings (not to mention I lack experience with hacking the reader).
David Thornley

0 vote down Jim:

I'm afraid I know of no compiler that will evaluate 'Socail' to 'social'. I thought I was the only one with a transpositional propensity!

Because many people find employeeSocailSecurityNumber just as readable as employee_social_security_number and it is shorter.

+3  A: 

What is the capital form of i? I (U+0049) or İ (U+0130)?

Capitalization is locale dependent.

The capital form of i is U+0049 since one programs in English and anglicizes foreign words in code.
The majority program in English. Should it be an absolute requirement of language design, though? I think being case-sensitive is less ambiguous. Also, the character U+0069 != U+0049. Outside (alphabet-dependent) natural language processing, why should it? I do not see any benefit.

Looks like people mostly agree that case sensitivity is important and I agree.

However, it can be annoying when you have to type something in the correct case so I think the IDE should let you type in the wrong case, but if you hit the auto-complete shortcut it should do case insensitive matching. This gives us the best of both worlds.

+2  A: 

The upper-case of a letter isn't a universal concept. Java uses Unicode, so if you wanted case-insensitive Java, the meaning of your program could change depending on what locale it was compiled in.

Most languages don't let you put dots or commas (or apostrophes or spaces) in the middle of integer literals, probably because that's also locale-dependent.

+1  A: 

From .NET Framework Developer's Guide Capitalization Conventions, Case-Sensitivity:

The capitalization guidelines exist solely to make identifiers easier to read and recognize. Casing cannot be used as a means of avoiding name collisions between library elements.

Do not assume that all programming languages are case-sensitive. They are not. Names cannot differ by case alone.

Tom A
+4  A: 


I believe this is a competitor to StackOverflow where you have to pay to read answers. Hmm... with case insensitivity, the meaning of the site's name is ambiguous.

This is a good reason for languages being case-sensitive. Less ambiguity! Ambiguity to programmers is considered yucky.

Scott Langham
the site's name was and is experts-exchange. (Ignoring a period of dot boom stupidity)
+3  A: 

I think having a case-sensitive language ENCOURAGES people to write poor code.

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize) { int ShoeSIZE = 10 return ShoeSize }

Duh. You couldn't think of a better variable name than "ShoeSize" for the different purposes???? There a billion different words you could use... but you choose to just keep using ShoeSize instead?

IME, the sort of people who write this junk in case-sensitive languages, don't write any better code in case-insensitive languages: they just use _shoesize, __shoesize, shoesize2, etc.

MyClass myClass; would be impossible with case-insensitive compiler.

Or you could be smart and actually use 2 different words... that better show what you are actually trying to do, like:

MyClass myCarDesign;


sometimes you do just want to call a "Date" a "date". being forced to add superfluous prefixes ("theDate", "myDate") is a pain when I know clearly that "Date" is a class and "date" is a variable.
+1  A: 

And you could also (foolishly) just use single-letters ("a" and "b" and "c") for all classes, variables, functions, and methods.

But WHY would you want to????

Use... names... that... make... sense. Not:

function a(a) { int a = a.a; return a }

Looks like proguard-obfuscated code. nice.
+1  A: 

Every example I've seen supporting case sensitivity is based on a desire to write bad, undescriptive code. e.g. the "date" vs. "myDate" argument - these are both equally undescriptive and bad practice. Good practice is to name it what it actually is: birthDate, hireDate, invoiceDate, whatever. And who in their right mind would want to write code like:

Public Class Person
    Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
    Public person As Person = person.PERSON
End Class

Amazingly this is perfectly valid case insensitive VB.Net code. The thought that case sensitivity allows you to even more flagrantly disobey good programming practice is an argument against it, not for it.