I don't see any use for case sensitivity in a programming language, apart from obfuscating code.

Why implement this in a programming language?


It looks like someone you know made a statement on this.

  • 34
    Why is there still case insensitivity in some programming languages? Commented Nov 27, 2013 at 23:45
  • 4
    Even English is case-sensitive in general. Common cited example is polish and Polish which are two different terms whose written forms differ only in case and which have different pronunciations and meanings. IMO its better for the programming lang not to be too clever in this regard and let the programmers themselves come up with appropriate written conventions. E.g. its quite common to write something like Person person = new Person() in OO language where the symbol 'person' is a temporary object and 'Person' is a class type.
    – Brandin
    Commented Mar 18, 2015 at 9:50

14 Answers 14


While case folding is fairly trivial in English, it's much less so in some other languages. If a German programmer uses ß in a variable name, what are you going to consider the upper-case equivalent? Just FYI, "ß" is only ever used in lower case. OTOH, "ss" is equivalent -- would you consider a compiler obliged to match them? When you get into Unicode, you get even more interesting problems, such as characters with pre-composed diacritical marks versus separate combining diacriticals. Then you get to some Arabic scripts, with three separate forms of many letters, rather than just two.

In the dark ages most programming languages were case-insensitive almost out of necessity. For example, Pascal started out on Control Data mainframes, which used only six bits per character (64 codes, total). Most such machines used the "CDC Scientific" character set, which only contained upper-case characters. You could switch to other character sets, but most had either upper-case or lower-case, but not both -- but used the same codes for both. The same was true of the ancient Baudot codes and such considered standard in the beginning days of COBOL, FORTRAN, BASIC, etc. By the time more capable hardware was widely available, their being case-insensitive was so thoroughly ingrained that changing it was impossible.

Over time, the real difficulty of case-insensitivity has become more apparent, and language designers have mostly decided ("realized" would probably be a more accurate term) that when/if people really want case insensitivity, that it's better handled by ancillary tools than in the language itself.

At least IMO, compiler should take input exactly as presented, not decide that "you wrote this, but I'm going to assume you really meant something else." If you want translations to happen, you're better off doing them separately, with tools built to handle that well.

  • 28
    +1, was going to say something similar, in my experience most people who whine about this are the same people who don't consider other languages/char sets. Commented Oct 6, 2010 at 20:23
  • 6
    My big question too, if the compiler's going to start noticing different spellings, should it allow you to arbitrarily put underscores in or other "word separators"? Will it maybe try to "do what you expect" when you misspell an identifier? How far will it go? (BTW, Ada allows underscores arbitrarily inside of numbers for clarity reasons.) Commented Oct 6, 2010 at 22:15
  • 3
    @Barry: The two are pretty much the same -- almost every other language on earth requires characters that aren't available in ASCII. For that matter, even though we sort of get by, it's really rather restricted even for English -- for example, it forces you to write "coöperation" as "cooperation". Fortunately, typewriters got people accustomed to such restrictions long before computers came along, to the point that few people even consider the possibility of using all the characters once considered necessary. Commented Oct 6, 2010 at 22:19
  • 2
    @dash-tom-bang: compilers have been written that tried to do things like that (correct spelling and what-not). Experience indicates that it's usually better to get the compiler to run faster and produce better error messages. Commented Oct 7, 2010 at 3:46
  • 3
    @phresnel Or "SZ". Good arguments can be made for both.
    – Vatine
    Commented Jan 26, 2012 at 15:42

Why would anyone WANT case insensitivity? In what scenario is it useful to be able to refer to a single variable as VARIABLE in one place, Variable in another, and variable in a third? Case insensitivity is exasperating. I’d much rather get a compiler error when I accidentally type VAriable instead of Variable rather than let case-typos like that slip into my code.

In conclusion, many programming languages have case sensitivity not just for historical/inertial reasons but because case insensitivity is a Bad Idea.

  • 14
    You're looking at it inside-out. Yeah, referring to the same variable with multiple spellings can be annoying, but it's nowhere near as bad as having two different identifiers referring to two different things, in the same scope, which differ only in case. Case insensitivity is a good thing because it prevents that. (Plus, it keeps a simple typo from becoming a syntax error; see the link in the question to Jeff's post on the subject.) Commented Oct 6, 2010 at 23:06
  • 92
    But I want simple typos to be syntax errors! I don't want simple typos in my code and I want my compiler to help me find them. Case insensitivity makes it harder to find them. Case insensitivity just seems like an excuse for sloppy coding.
    – nohat
    Commented Oct 6, 2010 at 23:39
  • 4
    @nohat: I agree, when you type anything other than what you intended to type, a syntax error is a good thing. Commented Oct 7, 2010 at 1:18
  • 17
    @Mason Wheeler, I have read the article and I simply couldn’t disagree more. I have used plenty of case-insensitive languages and I am constantly exasperated by case typos.
    – nohat
    Commented Oct 7, 2010 at 2:22
  • 15
    Absolutely agree with nohat - case insensitivity is a ridiculous idea - and usually the proponents come from people who still yearn for the good old VB/Basic days.
    – Tim
    Commented Oct 15, 2010 at 14:14

In Java case sensitivity is NOT used to provide more options in code, but rather for a very clear and consistent semantic meaning. ClassesLookLikeThis. objectsLookLikeThis. methodsLookLikeThis(). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. It does NOT provide greater freedom: it allows you to pack some information concisely into what is an otherwise overly verbose language.

I think that in explicitly statically-typed languages with mucho compiler and IDE support, case-sensitivity is a great way to communicate information (e.g., Java). With languages like Ruby, case insensitivity would probably cause even MORE unexpected results, though I'd be open to trying case-insensitive Ruby.

I think that case sensitivity with a strict system does not obfuscate code but actually makes it clearer. Consider possible Java code:

      joe blah = new hUf();

that's pretty clear, but what about:


In Java as-it-is, you would automatically know what this is. In case-insensitive Java, it's ambiguous, so you'd need to resort to some other mechanism to differentiate classes from instances from packages from methods. And THAT mechanism would probably make you vomit with how ugly it is :)

  • 2
    NOOOO! NOT MORE UNDERSCORES!! int package_class_method_var_name?!!
    – Michael K
    Commented Nov 3, 2010 at 12:42
  • 2
    @Michael, strange how nobody seems to notice that the underscore is a hassle to type. Commented Jan 28, 2011 at 19:59
  • 2
    it depends on your keyboard. For me (using a French keyboard), _ is easy to type, {} are much harder (using AltGr to reach them).
    – PhiLho
    Commented Mar 1, 2011 at 16:48
  • 6
    Ah, so case sensitivity is the new Hungarian notation. Commented May 3, 2011 at 21:44
  • 2
    That's kind of spurious: just because the compiler doesn't enforce it doesn't mean it doesn't exist. The conventions do enforce it, and programmers generally follow conventions. Commented Dec 5, 2013 at 17:48

If nothing else, it simplifies parsing and allows you more combinations for variable/class names.

With case-insensitive parsing, you'd be restricted to having to use unique identifiers, since 'myClass' and 'MyClass' would be the same thing. Alternatively, you'd have to add layers of complexity to your parser to make sure you could determine which identifier is used based on context.

Consider a case like this:

XmlWriter xmlWriter = new XmlWriter();

Suppose the XmlWriter class also has a static method called "Write". Are you calling it on the instance or on the class, if there is no case-sensitivity applied here?

  • 14
    Thats bad naming convention though. I would strangle somebody if write and Write were two completely different methods.
    – TheLQ
    Commented Oct 6, 2010 at 17:56
  • 5
    Gotta agree with TheLQ on this one. It drives me nuts when I'm working in some C library and I see declarations like "HWND hwnd;". Anyone who abuses case sensitivity like this oughtta be taken out and shot. Commented Oct 6, 2010 at 18:02
  • 4
    @TheLQ the methods have the same case. I was using different cases in the class/variable names as my example.
    – Adam Lear
    Commented Oct 6, 2010 at 18:16
  • 6
    @Anne Lear,I think this is a bad example. With a case insensitive language you wouldn't have to worry about what method to call because you'd already have a syntax error trying to use a class name for a variable name. Commented Oct 6, 2010 at 19:05
  • 6
    @Matt you shouldn't code without syntax highlighting. I can understand without an IDE, but coding in a editor without syntax highlighting... why would anyone do that to themselves?
    – Davy8
    Commented Oct 7, 2010 at 12:57

I don't think it was "implemented" so much as "allowed." Case sensitivity is the default state of string comparisons; it takes extra work for the compiler engineer to make a language case insensitive, since you need to add in extra code to perform case-insensitive comparisons and preserve the original token names for correct error and warning reporting.

That's almost certainly why it ended up in C; they wanted to make a simple language that was easy to implement a compiler for, at the expense of usability. As for why it's in modern langauges? Because it's in C, of course, so it must be the right way to do it! </sarcasm mode>

  • 3
    Plus, I think back in the 60s and 70s when programming languages were being invented, space and speed are VERY important. We can't afford those extra instructions and space for case-insensitve compares. It's more of a "that's the way it's always been done" problem in modern languages. There's no reason for new languages (like C#) to do this.
    – Jay
    Commented Oct 6, 2010 at 18:17
  • 2
    @Jay: And yet, for whatever reason, Pascal, which predates C and influenced its design, is case insensitive and still compiles faster. ;) Commented Oct 6, 2010 at 18:23
  • @Mason: I didn't think pascal influenced C... I had to look it up. Basically, they all come from Algol/Fortran! people.mandriva.com/~prigaux/language-study/diagram.png
    – Jay
    Commented Oct 6, 2010 at 18:41
  • 1
    @Matt: Umm... where are you getting that from? All the resources I've seen date Pascal to 1970 and C to 1972. Commented Oct 6, 2010 at 20:16
  • 17
    Kids these days. Back in my day, we didn't have lower case, and we liked it. 6 bits was enough. Of course, now we are all deaf from the SHOUTING.
    – KeithB
    Commented Oct 6, 2010 at 20:53

I like case sensitivity if for no other reason than it makes the code more self-documenting:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

I typically program in Python, but back in my C# days, I found it very convenient to name class instances the same as the class, but lower (or camel) case (as others have said):

Thing thing = new Thing();

Using case-insensitive languages requires some other convention for this, i.e., some sort of sigil like:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Which is a "bad thing".

I also find it convenient to grep (case-sensitively) to find reference to a class vs. uses of a variable. With a case-insensitive language, this would be less easy. Same for search & replace.

Lastly, as a programmer, when I see words with different cases, it jumps out to me that they are different things...I rarely have bugs where variable cases were wrong, even in dynamic, scripted languages where a compiler would have helped.


People pay attention to the shape of words before they actually read them. Case sensitivity keeps the shape of a symbol consistent throughout code. I also agree with those above that state that different conventions denote different types of symbols. Case sensitivity and insensitivity can both be abused. Bad programmers will always generate bad code... they will find a way.

Take language as an example. Why do we start sentences and named things with capitals... Is it also because of unix?

  • @JUST Comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this answer with others, please use chat. See the FAQ for more information.
    – Adam Lear
    Commented May 4, 2011 at 13:15

I think for statically-typed lanaguages like C# and Java, it doesn't actually add any value. Because in most cases, you've got an IDE that'll auto-correct case mismatches for you anyway, so at the end of the day, if I type in "VAriable" by accident, my IDE will auto-correct that to "Variable" for me. Add to that the MyClass myClass; style conventions and you can see that case-sensitivity is not necessarily a bad thing.

For dynamically-typed languages, there might be more of an argument, since it's harder for an IDE to guess an autocorrection, but in the case of dynamically-typed languages, you've already got so much more to worry about (in terms of typos) that using a consistent casing convention isn't going to add that much more burden.

So yes, while there's no real reason languages could not be case-insensitive, there's also no real reason why they should be either.

That article from Scott Hanselman about "SignOn" vs "Signon" was about string comparisons, and nothing to do with programming languages. I agree that strings that users type in should always compared case-insensitively, but I think that's a different ballgame to identifiers in a programming language.

  • 1
    +1 for mentioning the "IDE that'll auto-correct case mismatches"
    – DavRob60
    Commented Oct 7, 2010 at 12:27
  • 3
    IDEs are for wimps. I program with pencil and paper, and then scan the code in. Commented Oct 20, 2010 at 5:35

When a language is case-sensitive, I take advantage of it to reproduce conventional case usage in mathematics and science. Here is a list (by no means exhaustive) of some case conventions:

  • In probability theory, lower case f usually represents a probability density function (pdf), while upper case F represents the corresponding cumulative distribution function (cdf).
  • Also in probability theory, upper case letters denote random variables X, and the corresponding lower case letters denote their realizations x, as in $Pr[X=x] \leq 0.05$.
  • In linear algebra, upper case letters are generally used to refer to matrices while lower case letters generally are used to refer to numbers, e.g., $A=[a_{ij}]$.
  • Unit symbols are written in lower case letters (e.g., m for meter) except for liter (L) and those units derived from the name of a person (W for Watt, Pa for Pascal, N for Newton, and so on).
  • Symbols of prefixes that mean a million or more are capitalized (M for mega (millions)), and those less than a million are lower case (m for milli (thousandths)).
  • 3
    Valid point, but you'd be violating the coding conventions of almost every common programming language out there, which use case sensitivity for their own purposes..
    – Ken Bloom
    Commented Oct 15, 2010 at 14:14

I just figured it was because of Unix and C - but that's kind of a chicken and the egg problem which only the geezers can answer properly.

I use the rationale that the Chickens in "The Easter Bunny is Coming to Town" used when asked whether they came before Eggs. Because there were chickens on Noah's Ark, chickens came first. Therefore, because GCC runs on Unix, Unix came first, therefore because Unix cares so much for case, C and all its variants and descendants, yea anything that imposes curly braces, cares for case.

There probably is a link between curly braces and case sensitivity too.

  • Unix came many years before GCC, but the original BCPL compiler came before Unix, and it generally created the "C syntax". Commented Nov 27, 2013 at 23:53

In addition to the excellent answers given so far, I'd like to point out that case sensitivity gives you also additional "namespaces". For example Perl has some special blocks like BEGIN and END that run at different times than normal code (BEGIN at compile time, END after the normal program has terminated), and having those as all-caps makes them stand out, and means that the lower case variants aren't reserved words.

One can go even further and reserve all-uppercase names for future use by the language, and don't do any harm to normal programmers, who usually DON'T SHOUT IN THEIR CODE.


"Case sensitive" is always better for technical persons to reduce ambiguity. Take filename as an example. Dealing with Windows filename is more trouble than Unix filename because filename in Windows is case-insensitive while filename in Unix is case-sensitive.

Back to programming. For class name, method name, variable name, most language do not enforce the naming style rule. Sometimes for the sake of simplicity to do "reflection", we can simply use the "Case sensitive" name to bind to other data source without conversion, or handling the problem of same name but in different case.

  • Nonsense. It only appears to reduce ambiguity because you already expect the case-sensitive behavior. Commented Nov 27, 2013 at 23:47

I'm surprised by this rant. Now that nobody wants you to use an underscore or an m_ in a field name in C#, I've just been using camel case, and if the field name is the same as a public property name, just that the public property name is Pascal case and the backing field is camel case, I figure, "so be it" - that's what the programming community at large seems to want. It hasn't caused any problems so far.


Especially some programmer come from the early days of BASIC, where a variable name can only be 2 characters long.

And so, when it can be any number of characters, they become very happy. And along with case sensitivity -- because they don't want to also care about SomeName being accidentally equal to SOMENAME and cause a bug due to things like this.

Not the answer you're looking for? Browse other questions tagged or ask your own question.