The two languages stated are both dynamic languages. Case sensitivity has no buisiness in a dynamic language in my opinion.

I think it's a mistake to draw an analogy from standard written English, ie, the KEANU REEVES example, because in written English, case does make a difference -- if not in meaning (er, not always, but sometimes: compare "us" to "US"), but in function, where sentence-initial words are capped, proper nouns are capped, etc.

Anyway, I agree wholeheartedly that case sensitivity in entity names invites problems; the only sensible way to avoid those is to code with well-defined conventions for capitalization (e.g. Pascal capping, etc.). Has anyone come up with a good example of where using the same name with different caps for different entities is a good idea?

"but they are scripting language that do not resolve identifiers at parse-time"

This is a problem with scripting languages in general. Case sensitivity just happens to be one of the many ways that programmers can generate runtime errors. And this is exactly why I hate scripting languages. I seriously don't have any problem with case sensitivity when working with compiled languages. So are we really talking about case sensitivity or the shortcomings of scripting languages here?

Use a good compiled language instead... ;-)

I agree, case sensitivity has got to go. I've just started with Python (or is it python?) and have had the same problems with capitalization errors.

I'd go even further and say that the existence of two identifiers in the same scope differentiated by only capitalization is a code smell. Something's wrong if you can't come up with identifiers different enough to not rely on CS. Either you're not choosing very meaningful names, or there's a flaw in the design. I prefer a language that doesn't let me do it at all, it forces me to address that smell much sooner.

Why did the decision make more sense in 1972 ? (Except for the fact, as everyone pointed out, that the problem is even worse with interpreted languages).
Were they worried about the performance penalty on the compiler ?
Pascal was born before and is _not_ case-sensitive.

Remember that requiring exact case matching is much easier to support. Either the two names are exact matches or they aren't. You can end up with cononical issues with compilers when it comes to trying to determine if two strings are actually the "same" (differing only by case). Case insensitive comparisons are definitely much harder to do when you are dealing with more than just the standard English character set. There are now a whole bunch of extra string comparison functions in .NET to handle this because it is so difficult. So why make your compiler work that much harder just so that programmers can be sloppy coders? It just doesn't make any sense to me...

"So why make your compiler work that much harder just so that programmers can be sloppy coders? It just doesn't make any sense to me..."

Why not just code in assembly? Makes the compiler work *much* easier, and you don't have to deal with sloppy coders who can't manage register-allocation.

Making things easy for humans so that they can be sloppy is what computers are all about.

"So why make your compiler work that much harder just so that programmers can be sloppy coders"

From the "I jist don't git that whole compyooter thang" department...

> Were they worried about the performance penalty on the compiler ?

I think so, although I've never seen this stated definitively about the original 1972 C language. It was always positioned as a "mid-level language", eg, one step up from Assembly but sacrificing very little speed.

> Pascal was born before and is _not_ case-sensitive.

And I think that's because Pascal was a true "high level language", whereas C was sort of intended as a type of portable cross-machine assembly language.

I can't cite any sources to support these positions, though.. does anyone have any?

> So why make your compiler work that much harder just so that programmers can be sloppy coders? It just doesn't make any sense to me...

It's not about "sloppy coding". It's about the half-hour you spent tearing your hair out because you didn't notice that Object != object.

It's ironic that any developer would actually argue that case sensitivity helps us write code, because in my experience (and in many other developers' experience, as cited in my post) it's a giant productivity time sink-- a net negative!

Philosophical and religious differences aside, it has to be about *results*. Can anyone cite hard data supporting the idea that case-sensitivity lets us program faster?

> I can't cite any sources to support these positions, though.. does anyone have any?

I can't give you any official sources, but it's been said to me a quadrillin times, so it's at least within the realm of computing urban legend.

> It's not about "sloppy coding".

Case (in)sentivity has nothing to do with sloppy coding.

I suspect the problem with Python and PHP the original writer has is that it's not *entirely* case (in)sensitive. Pick one or the other and stick with it.

Wait a minute... what about the whole VB option strict nonsense? I can point to many ways that forcing case sensitivity helps us be more efficient.

Everyone here who is complaining is also probably using scripting languages that CAN'T catch casing errors as you code. I just don't consider this to be a casing issue. It's a scripting issue. Call it as it is and stop blaming your "poor productivity" on casing. You are just as like to type in a completely wrong identifier as you are to type one that simply differs by case so get over it.

As I said before, I don't have any problems with casing. I use C# and Java. If you choose to use a scripting language to "boost productivity" then that is your fault.

If I came across code in source control that used inconsistent casing in a language that allowed it, I'd fix it.

> You are just as like to type in a completely wrong identifier as you are to type one that simply differs by case so get over it.

Yup. In a case insensitive language, you'd end up bonking the previous value. In a case sensitive language, you'd get a compiler error.

"You are just as like to type in a completely wrong identifier as you are to type one that simply differs by case"

Not even close. Human beings remember words because they can make associations with the meaning of the words. Casing is an arbitrary distinction, it is disassociated from any meaning in the thing it refers to. The need to distinguish identifiers by casing means that you've failed to choose identifiers that capture the full meaning of the thing you are using them to represent.

It is objectively easier to remember to use "frog" when you are dealing with a frog and "horse" when you are dealing with a horse than it is to remember that "Horse" refers to the blue horse and "horse" refers to the green horse. Call them "blueHorse" and "greenHorse", and you won't need case sensitivity.

What he is saying is that it's easy enough to type "forg" as it is to type "frog" or "Frog".

> Pick one or the other and stick with it.

Unnecessary mixing is nasty too.

The canonical example is the one Scott Hanselman cites; URLs are *NOT* case sensitive, but the underlying file system *CAN* be.. which means you end up with things like /filename.txt producing a 404 to the file "Filename.txt" because you copied your website from a Windows box to to a UNIX box.

IMO, Unix webservers should honor the DNS insensitive convention since they're sitting under it. Mixing it up just makes things worse.

And you know what else is nasty? The de-facto default of all lowercase filenames in UNIX to avoid the constant specter of mismatches based on case. Another symptom of the case sensitivity disease.

> Wait a minute... what about the whole VB option strict nonsense?

That's a completely different issue, but it's evil for the very same reason: it causes developers to spend extra time debugging. This can be measured empirically; it isn't a matter of opinion.

> You are just as like to type in a completely wrong identifier as you are to type one that simply differs by case so get over it

So I'm as likely to type in "Cucumber" instead of "HtmlTag" vs. "HTMLTag"? This is news to me..

"Call them "blueHorse" and "greenHorse", and you won't need case sensitivity."

Now you are really grasping at staws. Of course, calling one thing Horse and another horse to designate between blue vs. green would just be plain stupid. That's not even the issue here. People want to be able to type something like horse and Horse interchangably without worrying about potentially generating a runtime error. But I still say that even if this was possible for your given scripting language, you would be just as likely to type hrse instead of either horse or Horse. So at what point do you think its ok for a language to forgive you for your typing mistakes?!?!

As a side note, I rarely get bitten by typing mistakes during coding. If I code all day long the comiler might catch one or two typing mistakes (if that many). Intellisense and related technologies go a long way toward fixing these types of "problems". So again, the issue is with scripting languages, not casing. You are spending all day long trying to find these issues because you are using a scripting language.

As a final thought for all of you scripting fanatics, even if "horse" is the same as "Horse"... what about "ho\u0052se"?

"So I'm as likely to type in "Cucumber" instead of "HtmlTag" vs. "HTMLTag"? This is news to me.."

LOL... no, but you are just as likely to type in "HmtlTag".

"So I'm as likely to type in "Cucumber" instead of "HtmlTag" vs. "HTMLTag"?"

Yes, I often type "stupid-selfish-bitch" instead of "mother-in-law". It's a common mistake. The letters are right next to each other on the keyboard.

re: case sensitivity - I think initially it was performance. It took more work to determine if two strings are equal in a case-insensitive manner. As far as why case-sensitivity has stuck around. The culprit I've seen pointed to most often has been Unicode. Apparently, it's hard to compare case between two different languages. Since it would be more work to retrofit all of the compilers, not to mention how much of the worlds code would break if case-sensitivity was abolished, it's left in.

Personally, I think it's pretty important. Would you rather have "aids" or "AIDS"? But I understand that compilers work differently.

I've tried really hard to get upset about this casing thing - and I just can't do it. It's just sooooo petty.

Previous comments about this being a 'scripting' issue instead of a 'casing' issue are right on the target. Its one of many tradeoffs that need to be considered when choosing a language.

Even if you do choose to use a scripted language, it's not that difficult for an appropriate editor to catch the casing error at edit time. it's even easier to catch the error with a quick static analysis of the code. If it bothers you that much - you could consider writing your own tool to catch the errors. This wouldn't be that difficult for PHP or python.

> Apparently, it's hard to compare case between two different languages

The last time I checked, the C# keywords weren't defined in Spanish or German. They're all English.

Furthermore, I've noticed that many foreign language speaking coders tend to stick to English throughout their code, even in the comments and variables. I guess it's another example of mixture avoidance-- just like avoiding mixtures of case-sensitivity and case-insensitivity. If you're going to learn the keywords in English, why not go all the way?

> So at what point do you think its ok for a language to forgive you for your typing mistakes?!?!

When they aren't typing mistakes. The words used in this sentence have the same meaning whether or not they are capitalized or not. Is "The" != "the"? Is "When" != "when"?

But in a larger sense, it's about empirical productivity data: how much time have you spent sussing out problems due to needless case sensitivity? Maybe you're the rare genius coder who never mistakes "SignOn" for "Signon" in a string somewhere.

Meanwhile, I'm still waiting for someone, ANYONE to provide a single link that provides any kind of evidence that case sensitivity is more productive. All I can find is "I just spent the last hour.." horror stories about case sensitivity.

Which of the following should the scripting engine forgive? At what point do you smack someone upside of the head and tell them to just be more careful? In other words, just how bad can someone mess something up and it still be the scripting engines fault for not being tolerant enough?

The correct spelling is HtmlTag:

1) htmlTag
2) HmtlTag
3) HTmLTag
4) Cucumber
5) htmltag
6) html
7) HTMLTAg
8) CucumberTag
9) taghtml
10) hTmLtAg

You get the point... I'm personally not very tolerant of these types of mistakes. I believe that things like "VB's option strict" and browsers that don't require well formed HTML are the bane of software development. Just how much time could we have saved over the years if Internet Explorer would simply have shown an error message instead of rendering crappy HTML markup that didn't even stand a chance of working?!?! Make it exact and you don't have any excuses. Try to guess or raise your tolerance level and programmers get sloppy and bugs get harder to find.

"The last time I checked, the C# keywords weren't defined in Spanish or German. They're all English."

As are ALL of the programming languages it seems. Even Ruby which was created in Japan and has a huge following over there. Weird, huh? There's a difference between keywords and variable names though. The source files are created using the default ANSI codepage, but they can be saved as Unicode (I believe UTF-16) files. So that means you can use identifiers in any Unicode based language including, I'm assuming, multibyte langauges like Japanese, Chinese, and Arabic. EXCEPT in C++, C++ still uses ANSI identifiers.

Argh, I should clarify the above statement. In Visual Studio, specifically VB.NET, C#, JScript.NET, and Java all use Unicode for their source files. I don't know about other IDEs/Languages. I think Xcode does Unicode source files as well.

Oh, on topic.

"Meanwhile, I'm still waiting for someone, ANYONE to provide a single link that provides any kind of evidence that case sensitivity is more productive."

I don't think it's productive, I think it's a necessary evil right now. My earlier statement was an attempt at a joke. I HATe case sensitivity in an IDE, but I HaTe it even more if the IDE doesn't help me be consistant by offering to correct my case as VB did.

I try to enforce a casing standard when I write sprocs, T-SQL keywords are uppercased, everthing else is lowercased or matches the entity/domain casing. There's no technical reason for me to do that, but I find it does make me more productive when I have to read over the statement later on. YMMV.

> Furthermore, I've noticed that many foreign language speaking coders tend to stick to English throughout their code, even in the comments and variables.

Go look at SAP. Read some of their ABAP code. I hope you know German really, really well. There's millions of lines of code, all written with really nice German documentation with lots of German variable names with nice English keywords.

I think this is much more of a scripting than casing issue. There are *MANY* pitfalls of run-time versus compile-time checking, not just case-related typos. You have to take the bad with the good if you are going to use a dynamic language.

But why not *learn* the tool and use it effectively? Perl has "use strict", PHP has "error_reporting(E_ALL | E_STRICT)" (PHP 5 at least) and as mentioned previously, VB has "option explicit" (I don't know of an equivalent for Python).

I think the "hours" of debugging people mentioned could have been cut short by just using these methods.

David said:
> If I came across code in source control that
> used inconsistent casing in a language that
> allowed it, I'd fix it.

The point is that in that language it's not wrong. You personally might not like it, but it is allowed.

Me personally doesn't like it, and one cool thing about some modern IDEs (not languages, IDEs) is that they highlight inconsistent casing and autocomplete with correct case.

I'd tend to support a coding standard that requires consistent case, because it's just one more thing that makes reading code easier. Mentally translating HTmlTags to htmlTags every time I see it slows me down and makes me less likely to notice the important changes that are actual bugs, like the use of hmtlTags instead of HTmLtaGS, htMlTags, HTMLTags or whatever other random casing the (ab)user typed.

Moz

> As are ALL of the programming languages it seems.

So why aren't programming languages localized, if everything else is (the os, the applications, the web)? What's so special about a programming language that makes it magically exempt from localization entirely?

> believe that things like "VB's option strict" and browsers that don't require well formed HTML are the bane of software development

Those are specious comparisons; neither of those things are comparable to "HtmlTag" vs "HTMLTag".. unless you consider <BODY> malformed HTML compared to <body>

The bottom line is productivity. Nobody (so far) can provide any evidence whatsoever that case-sensitivity makes programming any easier or faster, but I can find *lots* of evidence that it makes programming slower and more painful.

> In other words, just how bad can someone mess something up and it still be the scripting engines fault for not being tolerant enough?

Getting the letters correct in a variable name is hard enough. Case is only a significant difference if you're a computer, not a human being. The meaning of the word "Cucumber" doesn't change if I type it "cucumber". Forcing the developer to use the exact same case or smashing their face in with a compile error is just plain cruel and unusual punishment-- death by Von Neumann.

Plus, case insensitivity has another benefit: it prevents developers from doing things like calling variables in the same function I and i, or discriminating between public and private variables purely by case.

> Nobody (so far) can provide any evidence whatsoever that case-sensitivity makes programming any easier or faster, but I can find *lots* of evidence that it makes programming slower and more painful.

So, do you have any proof that case-insensitivity makes programming easier or faster, other than someone's (including yours) opinion?

Look, English as a language *sucks*. There's so much ambiguity in English as a spoken language that it was inevitable that some of it would spill through into programming

Even the fact that English has case makes it more complicated than most languages need to be. Perhaps we should all code in Korean, since it has no notion of case, no homonyms, no silent letters, no crazy "i before e, expect after c, except for science" rules, is totally phonetic and has very strict grammar rules that makes it murderously even for the most inept person to learn how to read and write it.

>But why not *learn* the tool and use it effectively? Perl has "use strict", PHP has "error_reporting(E_ALL | E_STRICT)" (PHP 5 at least) and as mentioned previously,

I agree with David's comments. Let the compiler help you out by setting strict options (if the compiler has them).

Plus, these days the new IDEs include features which highlight possible problems (like casing/variables not declared, etc) even before you compile.

The casing "scandal" is certainly not something that'll catch you out after you compile and are running. That's a problem for scripting languages or VB. So what's the big deal?

I guess this whole baggage that such languages as C/C++ bring with their case-sensitivess is why the .NET CLR is case-sensitive. For languages like VB.NET it's the compiler which has to be made to jump through hoops for the language to remain case-insensitive while the CLR is sensitive about the whole case issue. Then again, VB.NET is no fun at the best of times… <a href="http://www.cafepress.com/radioactivecode">http://www.cafepress.com/radioactivecode</a>

Well... I give up. I still say that this is entirely a scripting language issue. No one has been able to show that there is any productivity increase or decrease with either of the two methods.

Given that this issue doesn't impact me in the least, I will just chalk it up to yet another reason not to use scripting languages. Just make sure you remember it the next time someone is trying to tell you that scripting languages make programmers "much more productive" than compiled languages. Yeah... uh huh.

Now this is funny, I blogged about how just a worthless debate this about a month ago when I had to endure yet another "It's great/It sucks" debate by my junior programmers. So much passion, wasted.

<a href="http://www.enginefour.com/blogs/shawn/2005/10/worthless-programmer-debate-1-case.html">http://www.enginefour.com/blogs/shawn/2005/10/worthless-programmer-debate-1-case.html</a>

I'm curious where VB.NET fits into the defintion of "scripting languages."

> I blogged about how just a worthless debate this about a month ago when I had to endure yet another "It's great/It sucks" debate

You're just gonna love my next post, "when does human life begin: a woman's right to choose"!

I realize that Microsoft isn't going to make C# case-insensitive on my behalf (although they should). I'm trying to save the next generation of frameworks from the horrors of case sensitivity.

> No one has been able to show that there is any productivity increase or decrease with either of the two methods.

Actually, I can pull up a dozen case sensitivity horror stories without even breaking a sweat. Can you find even *one* example where case sensitivity actually helps a programmer? Here's an example:

--
http://forum.java.sun.com/thread.jspa?threadID=638387&messageID=3736785

So the problem was that instead of
gBuffer.setColor(Color.BLACK);
I should have used
gBuffer.setColor(Color.black);

The ***** (Java) wasted half of my day because of a case error. I understand that Java is a case-sensitive language, but why would it then let me use (and even propose the usage of) CAPS name when the browser Java wouldn't actually allow it?
--

Yeah, let's get rid of case sensitivity; then replace semi-colons with whitespace or carriage returns; then the whole curly-brace thing can go in favour of constructs in plain english. Then all languages will be the same - derivatives of BASIC! Yeah, right on. Why not just stick to languages that work the way *you* expect, and leave the rest of us to take care of casing.

> The ***** (Java) wasted half of my day because of a case error. I understand that Java is a case-sensitive language, but why would it then let me use (and even propose the usage of) CAPS name when the browser Java wouldn't actually allow it?

But case sensitivity wasn't the problem in your example! Read the rest of the thread - the uppercase constant, Color.BLACK, was added in JRE 1.4 and the user was running this in a browser with a 1.3 plugin. The problem was using different versions of the JRE, coupled with a crappy browser implementation that didn't notify the user about the error.

He would have wasted the same amount of time if they would have changed Color.BLACK from a long to an object from 1.3 to 1.4.

I don't think that Jeff is looking for real empirical studies.

Can anyone even come up with an anecdote where case-sensitivity was helpful while programming? Come on, even a friend-of-a-friend.

A friend of a friend of mine worked for a guy who was so sloppy that he would constantly type HtMlTaG or hTmLtAg instead of HtmlTag. Thank goodness the compiler would flag it as an error. Can you imagine how much time would be wasted by programmers trying to read this guy's code?!? Maintenance costs would go through the roof!

Wouldn't it would be ridiculous to even have naming standards for coding if you didn't also specifiy rules for casing? So it appears to me that naming standards is a pretty good non-empirical benefit of requiring case sensitivity.

All this arguing is silly. I have one golden rule: Case-perserving, not case-sensitive.

In my experience, most people who scream for case-SENsitivity are really only concerned with PERSERVING case. They still haven't gotten over mS-dOS manging their pretty 8.3 file names.

I TEND TO AGREE CASING IS IRRELEVANT AS IS CORRECT SPELLING AND PUNCTUATION PROGRAMMING SHOULD BE EASY COMPUTERS SHOULD DO WHAT I WANT THEM TO DO NOT WHAT I TELL THEM TO DO THIS MAKES COMPUTERS MUCH MORE PREDICTABLE

I agree with Armen:

In Visual Basic, you declare a variable, for example, as:

Dim strName as String

Now, if you type

strname= "Coding Horror"

or

STRNAME="Coding Horror"

the IDE "corrects" your code after you press the ENTER key so that it appears as this:

strName = "Coding Horror"

The benefit of this is that if you type

strnam = "Coding Horror"

the variable name doesn't "fix" itself; it shows that you made an error.

Sounds as though we need better tools.

1) Identifiers that are different things shouldn't look too much like one another. It's confusing, and a potential source of bugs.

Example: cur1 and curl are two different identifiers, but you'd quickly glance over it. Indepedently of whether they're used in a case sensitive language or not.

With that established:

2) The only point in case insensitiveness is being allowed to write the same identifier in different ways. So you could write HTMLTag at the top of your sourcefile, HtmlTag in the middle, and at the end you are too tired of typing to hit the shifts so you are conveniently allowed to type htmltag.

Would you do this?

Even if the language I'm programming in is case insensitive, I'll still case the identifiers the same each time. Doing otherwise just looks messy. And I'm willing to bet a lot of other developers do it the same way.

So where's the issue? Even if your language allows case insensitivity, you're not going to use it. To give lazy developers to write messy code?

It's just like another topic of heated debate: Python's indentation-based scoping. Love it or hate it, but blocks are *required by the language* to have consistent indentation. Again, this helps writing better-looking code, and since it's built into the language there's no way around it for lazy/messy developers.

I guess my post has come off a bit as pro-case sensitivity, but I really don't care either way.

Jeff -

From the sounds of your rant, looks like you have NOT been using VB.NET lately huh?

Ever think of coming back to the dark side?

> the IDE "corrects" your code after you press the ENTER key so that it appears as this:

The original article I cited is title "The Case for Case-Preserving, Case-Insensitivity", so case preservation has always been on the table.

> Can anyone even come up with an anecdote where case-sensitivity was helpful while programming? Come on, even a friend-of-a-friend.

I'm still waiting.. but in all seriousness, this is my point. If a feature is painful, people complain about it. A lot. That's not opinion, that's empirical data.

You can find similar horror stories about "OPTION EXPLICIT" all over the place. And nobody seems to dispute the idea that having the compiler auto-declare variables for you is a bad one.

Here's another:

http://dev.mysql.com/doc/refman/5.0/en/name-case-sensitivity.html
--
Be very careful with [the Identifier Case Sensitivity] option. I have had a difficult time migrating from 3.23.x on Mac OSX to 4.0.x do to this option being turned on by default. After restoring from a mysqldump bakup, I would get inconsistent results. Since none of my loading batch scripts or processing scripts changed (all used our standard naming convention with upper case in table names), the inconsistency must have come from a change in 3.23.x to 4.0.x . A simple change of this flag to '0' fixed the problem, but only after hours of verifying our data and backups.
--

I suspect that all the people complaining here about how ugly case-insensitive code looks, or how good coding standards should require consistent variable naming, have never actually tried using a case-insensitive language with a good IDE that standardises the casing automatically.

Case insensitivity does NOT need to mean that variables are shown as you type them, as Gary's example clearly shows.

"So you could write HTMLTag at the top of your sourcefile, HtmlTag in the middle, and at the end you are too tired of typing to hit the shifts so you are conveniently allowed to type htmltag.
Would you do this?"

Absolutely. That's what I do all the time. In VB.NET I only type HTMLTag once, when declaring the variable, and thereafter I type htmltag and let the IDE change it to HTMLTag automatically.

I totally agree with Jeff: case sensitivity has no upside, and is just a waste of my time.

"And nobody seems to dispute the idea that having the compiler auto-declare variables for you is a bad one."

Says who? I've seen idiots out there who dispute this as well.

"I'm still waiting.. but in all seriousness, this is my point. "

So you don't accept my argument/example which states that you can't have true variable naming conventions without also requiring specific casing? For example, what good is it to say that variable names must start with the type if people can all use the following to indicate the same variable name?

InTeGeRDAYSoLd
integerDaysOld
INTEGERDAYSOLD
IntegerDaysOld

You've got the most important case against case insensitivity there is... consistency. What more do you need?

And I'd be interrested in seeing the empirical evidence that shows the true "cost" of case sensitivity vs. case insensitivity. I would be willing to bet that over the past 30 years, the benefit of reduced compile times (conisder ALL of the compiles that have been done by EVERY developer using Java, C, C++, C$, etc.), and reduced maintenance costs from consistent naming conventions will FAR outweigh you miscellaneous debugging nightmares being experienced by a VERY small percentage of the programming population. It just HAS to be the case that case sensitivity has benefitted the many much more than it has hurt the few.

One of my naive 1997 rants is on this very topic. I'm a Linux/Unix/Win/OSX guy and still oppose almost all instances of case sensitivity. I've been bitten many times; but OTOH I've looked smart sometimes when I've been able to tell a colleague "oh, it should be 'X11', not 'x11'; that's the problem".

For programming environments stuck with it, code databases, search and autocomplete can mitigate the problem.

Compound words in mashed-together variable names, er, "compound" the problem: ShutDownPort vs. ShutdownPort, that sort of thing. Mainly because of this I've gone to all lowercase identifiers with underscores (which ironically will not fix the example above). But a reasonably smart syntax checker could say "Hey, your case is borked here, and you actually declared it this way; fix?"

Case sensitivity tends to infect cross-platform stuff and force things its way. You can't fix C++ without breaking linkers and code. You can't even have a case-insensitive web server for a case-insensitive filesystem; multiple URLs pointing to the same file might still be considered distinct by search engines, analysis tools, proxies, firewalls, etc.

I still think case-insensitive-but-preserving local filesystems are the way to go.

Unicode introduces problems for case-insensitive collation and matching: <a href="http://www.unicode.org/unicode/faq/casemap_charprop.html">http://www.unicode.org/unicode/faq/casemap_charprop.html</a>
Some characters either don't have matches in other cases, or many may map to one, or a case switch may even change string length (think of 'fl' ligature, German soft s, etc)

Interesting: 'ls' in Linux has been case insensitive for some time now.

> Can anyone even come up with an anecdote where case-sensitivity was helpful while programming? Come on, even a friend-of-a-friend.

Case sensitivity helps as a pnuemonic device.

Case sensitivity makes the programmers intent clearer - a reader won't have to guess if htmltag or HtmlTags refers to the same 'tag'.

Case sensitivity, in some cases, could help in text searches. I hate searching for a keyword and not being able to find it in notepad just because the 'case' radio button was set the incorrect way. ( this is kind of a lame and picky point to make - but so is complaining about case insensitivity. )

generally, case sensitive languages aren't that difficult. I certainly haven't ran into the problems that have been described, and I've coded a lot in both scripted and compiled languages. When I have ran into an error - it's been something that I can fix within a few seconds - maybe a minute at most.

On the other hand, case insensitivity leaves the door open for sloppy coding style that makes others second guess your intent, and drives me crazy when I look at it myself.

In VB.NET I only type HTMLTag once, when declaring the variable, and thereafter I type htmltag and let the IDE change it to HTMLTag automatically.

GENIUS!!! i hereby declare that we just let the ide's write the code.

I have a real-world, honest-to-goodness example of where case sensitivity was not only required, but helpful. I built an accounting and reporting framework at one of my previous jobs. It was a printing company that printed bank statements, billpay checks and what not. Well one of our print jobs was to print billpay checks for one of our customers. This customer actually consisted of hundreds of child customers for whom it was printing checks. Two of their customers actually had the exact same name that differed only by case. I can't remember the exact same name, but let's just say BankOne, and Bankone (there actually is a BankOne, but I'm just using it as an example).

Whenever I pulled back a query and ordered the report for this customer by bank name, I would get fouled up orders for these two banks. It would show up similarly to this:

Value1 Value2 Value3 BankOne
Value1 Value2 Value3 Bankone
Value4 Value5 Value6 BankOne
Value5 Value5 Value6 Bankone

Where it should have been grouped by the actual bank name, case sensitive and all. So I changed the collation for the bank name column so that it would be case sensitive and it pulled back the data back in the correct order:

Value1 Value2 Value3 Bankone
Value5 Value5 Value6 Bankone
----------------------------
Value1 Value2 Value3 BankOne
Value4 Value5 Value6 BankOne

(formatting was put in there for readability, I did all of that in the middle tier).

Here's my personal opinion on case sensitivity: I prefer my compiled languages to be case sensitive. VB drives me nuts sometimes. However, I think that scripting languages that generally are used outside of a robust IDE should NOT be case sensitive. Since I have started using Visual Studio and C#, I have not had one instance where case-sensitivity hurt my productivity. If I declare a variable, and then later on type it with different casing, then I am notified. It's not something that I will pull my hair out until I find it, the latest time I will discover the problem is at compile time(in VS 2003 without resharper).

Here's another little caveat: I think that any function that gets passed a string variable should attempt to be insensitive to case. For example, if I'm working with a DataRow object named dr, then dr["ColumnOne"] should be the same as dr["columnOne"].

One more caveat: It would be exceedingly stupid for a developer to name two different members, methods, or properties the same except with a different case. ToString() and toString() should never be seen. For one thing, there's nothing that says why they are different. Another reason is that it breaks the ability to use either method in VB.NET when referencing the object.

Sorry for the long post, if I had my blog up and running, I would have simply replied there and provided a link.

> For example, what good is it to say that variable names must start with the type if people can all use the following to indicate the same variable name?

Then what good are numbers? I can use all of the following to mean the same thing:

12
12.0
24 / 2

Similarly, I can refer to my wife as:

Betsy
Bitsy
Liz
Beth

All totally valid forms of the name "Elizabeth".

People intuitively know that a variable "HtmlTag" is equivalent to "HTMLTag". Computers don't. Why should we penalize human beings to save a zillionth of a second of computer time? Computers get faster every day; our brains don't.

> Since I have started using Visual Studio and C#, I have not had one instance where case-sensitivity hurt my productivity

I type lower case "console" all the time, and it's wrong every single time. Pop quiz: is it Exception or exception?

I'm totally for relying on the IDE to enforce consistency, but the other way around: let it be optional: case insensitive but case preserving. In other words "preserve" the way the token was originally cased.

> It would be exceedingly stupid for a developer to name two different members, methods, or properties the same except with a different case.

It is exceedingly stupid, yet it happens ALL THE TIME. Case sensitivity lets the worst instincts of developers run wild.

And similarly, don't you think it's more than a little dangerous to have two customers distinguished by the difference between "BankOne" and "Bankone"?

"People intuitively know that a variable "HtmlTag" is equivalent to "HTMLTag". "

No they don't. And they don't intuitively know that HtMlTaG is equivalent to hTmLTAG. They need to scan it very closely. You know this... I'm not sure why you are clinging to it so hard. It's obvious to everyone else but you that casing impacts readability and that humans can not distinguish casing differences as quickly or easily as computers do. It is also obvious that computers can compare two strings quicker using exact case than they can using case insensitivity.

"I type lower case "console" all the time, and it's wrong every single time. Pop quiz: is it Exception or exception? "

It's obviously Console and Exception. Why? Because Microsoft specifies casing rules when they talk about naming conventions (sound familiar?). I'm not sure why you have problems with this but you might want to brush up on your .NET naming conventions. .NET is a heck of a lot easier in this regard than Java is. Every public method/property/class/field is capitalized.

All you have to do is post another blog entry to get us off of this topic... or just admit that casing realy isn't as big of an issue as you are making it out to be. ;) Why is it so darn hard for people to admit they are wrong? Or even admit that they aren't as right as they think they are?

I agree that case sensitivity is not a necessary thing. But when a language let you bite your own foot by letting you use any undeclared variable and not inform about it, I blame the language. I hate scripting languages because this solely reason (spent hours trying to find why my "shoping cart" was always empty.)

> And they don't intuitively know that HtMlTaG is equivalent to hTmLTAG. They need to scan it very closely

You're citing a pathological case. "HTMLTag and HtmlTag" are as equal as "matt and Matt". Which one are you?

> Why is it so darn hard for people to admit they are wrong? Or even admit that they aren't as right as they think they are?

> It's obviously Console and Exception.

Yes, obviously, because when I type "console", I couldn't possibly be referring to "Console".

>Why is it so darn hard for people to admit they are wrong? Or even admit that they aren't as right as they think they are?

Like the abortion question I referenced earlier, this is ultimately a religious issue. Either you think case is significant, or you don't.

Given the vast number of case sensitivity horror stories out there*, I was hoping people would have a little more empathy for their fellow developers.

* Here's another: http://wordpress.org/support/topic/23792

In response to:

> * Here's another: <a href="http://wordpress.org/support/topic/23792">http://wordpress.org/support/topic/23792</a>

lets compare apples with apples here. It seems that most of us are talking about case sensitivity as it applies to programming languages, not the users experience. In the cited example, I think it's obvious that case insensitivity is the correct way to go - but that doesn't make it true for PHP or C#.

(You could just as easily have developed the logon dialog with a case insensitive language, and the user logon may still be case sensitive...)

> It seems that most of us are talking about case sensitivity as it applies to programming languages, not the users experience

So developers aren't users? How does it suck any less to type case-sensitive data in a login form compared to my IDE?

I think developers are users too:
http://www.codinghorror.com/blog/archives/000239.html

I'll agree: I didn't say that programmers aren't users - but I would say that that when I, as a programmer, develop, I expect case sensitivity in my language. And when I log on, I think Case insensitivity is the way to go. they are two different things.

You can make an argument for case insensitivity in logging on, but that mean the same argument applies to programming languages. when I said we should 'compare apples to apples' that's what I meant.

So why do some people WANT case sensitivity so badly? Do you routinely name variables the same name only with case differences?

Quick, non-scientific poll of the people arguing in favor of case-sensitivity. How often do you have two or more variables whose name differs only in case?
e.g. int foo;int Foo;foo = Foo;

The only difference between statically typed, case-sensitive langauges and dynamic scripting languages is the time at which you are notified of your casing error.(at least as it applies to case-sensitivity). With compiled languages, the compiler tells you that you have an undeclared identifier. With scripting languages, the error can be harder to trace down and occurs at runtime (or during your unit test). Neither one prevents you from making the casing error in the first place, EXCEPT the VB IDE. ;)

"I think Case insensitivity is the way to go"

Well, that's a whole other kettle of Pandoras box.You reduce the complexity of a password by making it case-insensitive. But's lets focus on the current holy war. ;)

"And they don't intuitively know that HtMlTaG is equivalent to hTmLTAG. They need to scan it very closely."

So if I say ,"I have aids" what do I mean? What about, "I have AIDS"? What about "I have aids to help me." The only difference is the context, which the brain picks up on very quickly. Much quicker than any, and I mean any, computer. Provided the context between hTmLTAG and HtMLTaG doesn't change, it's easy for humans to note the difference and note that the case difference doesn't matter.

I'm surprised that noone has mentioned a related issue: XML markup case sensivitity. HTML markup is case-insensitive but XML markup is not. Why? According to Tim Bray:

---- quote ---- quote ---- quote ----
XML markup is case-sensitive because the cost of monocasing in Unicode is horrible, horrible, horrible. Go look at the source code in your local java or .Net library.

Also, not only is it expensive, it's just weird. The upper-case of e' is different in France and Quebec, and the lower-case of 'I' is different here and in Turkey.

XML was monocase until quite late in its design, when we ran across this ugliness. I had a Java-language processor called Lark - the world's first - and when XML went case-sensitive, I got a factor of three performance improvement, it was all being spent in toLowerCase().
---- quote ---- quote ---- quote ----

So for XML it was mostly a performance issue, not a developer preference...

Scott scott = new Scott()

Scott myScott = new Scott()
Scott AScott = new Scott()
Scott aScott = new Scott()
Scott theScott = new Scott()
Scott person = new Scott()

"Quick, non-scientific poll of the people arguing in favor of case-sensitivity. How often do you have two or more variables whose name differs only in case?"

All the time... but they are always related. The .NET naming conventions would tell me to have a private member that is pascal cased and an associated property that is camel cased (did I get that right?).

So I have the following...

private string lastName;

public string LastName
{
get { return lastName; }
set { lastName = value; }
}

Yes... they differ only in the casing of the first letter.

I've never programmed in C# yet, but don't most people do this in C#? -

private string _LastName;
public string LastName
{
get {...}
set {...}
}

btw I think lastName and LastName are both camelCased, only the first is in lowerCamelCase (or just camelCased) and the latter UpperCamelCase (which is the same as PascalCase)

(<a href="http://en.wikipedia.org/wiki/CamelCase)">http://en.wikipedia.org/wiki/CamelCase)</a>

Joost,

That's normally how I name things. My private member vars are prefixed with "_".

Matt, I think the official guidelines only specify naming conventions for protected members and public fields.
<a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconcapitalizationstyles.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconcapitalizationstyles.asp</a>

"Protected instance field Camel redValue

Note Rarely used. A property is preferable to using a protected instance field.

Public instance field Pascal RedValue

Note Rarely used. A property is preferable to using a public instance field."

They do have a section dedicated to helping devs navigate the complex field of case-sensitivity.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconcasesensitivity.asp

In fact, telling developers to avoid the naming convention you are using.

"Do not use names that require case sensitivity. Components must be fully usable from both case-sensitive and case-insensitive languages. Case-insensitive languages cannot distinguish between two names within the same context that differ only by case. Therefore, you must avoid this situation in the components or classes that you create."

Thanks for the clarification on camel vs. pascal casing. I never get that right. You are also right about naming conventions of private members. I actually use the following but only because I saw it once and liked it. Note that it does NOT jive with what the VS forms designer does for the controls that are added to your form.

private string _lastName;
public string LastName
{
get { return _lastName; }
set { _lastName = value; }
}

The main reason I do this is because it is more clear when trying to come up with similar names for method parameters (which end up being publicly visible to coders).

Thus the following makes more sense to people using my classes:

public void initializeNames(string lastName, string firstName)
{
_lastName = lastName;
_firstName = firstName;
}

"So why make your compiler work that much harder just so that programmers can be sloppy coders? It just doesn't make any sense to me.."

"On the other hand, case insensitivity leaves the door open for sloppy coding style that makes others second guess your intent, and drives me crazy when I look at it myself."

How clear is the intent is this example interface? (yes i actually ran into this in someone's production code)

public int myProperty;
public int MyProperty
{
get { return myProperty; }
set { myProperty = value;}
}

Which version of the "myproperty" do you call? Is this not sloppy code allowed because C# is case sensitive?

(An interesting point the code above compiles great and you could call it from VB.NET 2003 however you can't call into this from VB.NET 2005 because it detects the ambigous name)

You can't write an interface like this in VB.NET because this code:

Public myProperty As Integer
Public Property MyProperty() As Integer
Get
Return myProperty
End Get
Set(ByVal value As Integer)
myProperty = value
End Set
End Property

will give you a compile error stating:
'MyProperty' is already declared as 'Public myProperty As Integer' in this class.

"Which version of the "myproperty" do you call? Is this not sloppy code allowed because C# is case sensitive?"

No, it's just sloppy coding period. It would have been just as sloppy and confusing if they had done this:

public int my_Property;
public int MyProperty
{
get { return my_Property; }
set { my_Property = value;}
}

You still wouldn't know which one to call and the casing issue has been removed. Sloppy coding is sloppy coding. And not enforcing case sensitivity allows coders to be even more sloppy.

<i>You still wouldn't know which one to call and the casing issue has been removed. Sloppy coding is sloppy coding. And not enforcing case sensitivity allows coders to be even more sloppy.</i>

This is the fundamental difference between the two camps of programmers. There are those at think "You should have the freedom to shoot yourself in the foot" and the other camp that advocates gun control.

Good point. And I'm obviously one who advocates "gun control". ;)

Heh, that "gun control" comment might be the wittiest thing I've ever said!

Crap code is crap code. Shit heads who can't grok camel-case (or whatever) and use it consistently NEVER WILL. They just don't f'ing care.

The worst possible situation is a case insensitive language that doesn't require declarlations. OMFG, you're lucky if you survive with your pinky toe when dealing with these lazy coders.

Case-sensitive w/ declarations languages are free from these dangers, so there's no real need to discuss them.

What really drives me nuts are case-sensitive completion engines and file-systems.

> Good point. And I'm obviously one who advocates "gun control". ;)

Well, I have to go back to the "it's a religous issue" position.

That depends on your definition of "gun control". For me "gun control" is a language that DOESN'T let you declare "myProperty" and "MyProperty" in the same scope. For you, it's a language that does. Which from my perspective, is some darn poor gun control ;)

As with anything, the use of scripting languages has its advantages and disadvantages. What you lose in the time spent tracking down the case sensitive variable bugs, you gain in faster development throughput in not having to compile the code over and over again. Over time, you become more careful with your variable naming, become less sloppy, more disciplined in your use of conventions and this makes you a better programmer.

Plus, if you test all new code as you write them, develop a unit test suite (recommended by Bram Cohen himself for python development), then you learn to identify these case/mispelling bugs quickly and end up minimizing them in the future. I for one never had these casing-related problems because I'm naturally meticulous with my code. But I can understand why other developers can get nasty bugs with casing. To each his own I would say. Just don't blame the scripting languages please.

Let me preface this by stating that I am a very anal retentive person. I pay great attention to detail and love digging way down into code. If I can dig into an abstraction and traced it down to it's real representation in numbers, it makes sense to me, otherwise I am nervous that whoever wrote it didn't pay enough attention (read: as much attention as I 'think' I do :p ). I am a big fan of minimal abstraction in all cases. So to me case sensistivity does make sense. I have never encountered a problem with capitalization in my code that has not been obviously and squarely my own fault for not paying attention to what the heck I was typing. Quite simply, 'a' and 'A' are 2 different numerical values as characters so 'and' and 'And' of course are different entities. For high level scripting languages, in which the numerical value of 'a' and 'A' need never be calculated, sure case sensitivity can be abstracted away. But for more machine-powerful languages, such as C/C++, you simply cannot do away with that distinction. Anyway, just felt the desire to toss my 2 cents in the hat. Happy trails!

I know I'm really late of this and few will read it, but as guy whose already written one language runtime (installed on 50 million computers BTW) and is currently creating another compiler and runtime, I thought I'd weigh in.

Case insensitivity in scripting-languages is a performance drag, because when comparing identifiers it can't just compare the raw bytes, special logic must be used to compare each character.

When I was performance profiling my first runtime, I found a large amount of time was spent lowercasing identifiers so that variables could be stored and retrieved from the runtime hashtable in a case-insensitive manner. I had to do a lot of optimization work to reduce that penalty, and while I figured out some good optimizations and made it a pretty much a non-issue, it will never be as fast a fully case-sensitive solution.

My gut feeling is that most creators of dynamic languages make the case sensitivity decision simply due to the performance benefit (statically compiled languages have no such excuse, but since most require you to declare identifiers the compiler will alert the developer before its a problem). It's understandable, how can you not be concerned about performance when writing a programming language (even its just a small performance difference)?

I am definitely in the camp that dynamic languages should be case-insensitive. But I don't think that you should just write code with random case just because the computer doesn't mind. Code should be written with consistent case (as if the language is case sensitive) for the benefit of other who have to read the code. That way the code looks consistent, but if there is a case problem it won't fall over when it hits that rarely called chunk of code (and probably at the worst time).

Old IBM terminals had a setting on them that capitalized everything when you hit enter. I always coded in all caps, which seemed normal to me. The only drawback I ever experienced was if you were displaying a lower or mixed case literal, you needed to be careful when editing that line of code.

The one that really gets me is the programs that don't work for some things because they expect Windows to be case-sensitive for filenames (apparently this is Windows fault, not the programmers). The argument for it is ensuring the code-base is "cross-platform compatible" (ie: does not work on the Windows platform).

But the clincher for me yesterday was this: how hard it is to do basic string operations in a language (which will remain nameless, as to be fair it is still in beta and this may change) where the string functions are case-sensitive and there is no parameter to switch this behaviour off.

In any other case, one line of code would find the location of a substring within a string, or replace it. But with case-sensitivity forced upon you, dealing with real world strings is impossible unless you are only interested in pre-defined tokens. About the best compromise is to write the code three times for upper-, lower- and sentence-case, but then you still miss the sloppy data entries where it is random.

If you have a problem with case sensitivity, don't use caps ! If you want to highlight a term, Use an underscore, a dash etc between "words", instaed of caps. Maybe you could use caps for CHARS, and not for integers ? Why not attack Linux for being case sensitive while yer at it ?

I've found the following coding standard quite useful, no matter which language you use:

- I never use names that differ only by case, so I wouldn't use an identifier "someObject" and also "SomeObject" or "someobject", I always let the identifier differ by more that just upper/lower case (in every language).
Reason: It's just so much easier to have indentifiers that _not_ only differ by case.

- I alwas use the same way of writing an identifier, so even if "someObject" and "SomeObject" are the same in the particular language, I allways call it "someObject", not "SomeObject".
Reason: Because when writing code in different languages, you don't get into trouble becase one language is case sensitive, the other is not.

- I use long names that can carry a meaning, I try to avoid using names that are shorter that tree or four letters.
Reason: Identifiers like "i", "c", "f" don't carry any semantic as to what is stored inside (if the identifier is a variable). It helps understanding the code if the identifiers are a bit more verbose.

- If the compiler/interpreter has got a switch to be more strinct, I use it, because it helps much when finding bugs (or avoiding them alltogether), because if you have to declare variables before use, you get told if you misspell one of them.

For example, I use the following if possible:
C/C++: "-pedantic -Wall -ansi"
PHP: "error_reporting(E_ALL);" (sometimes even "error_reporting(E_ALL|E_STRICT);")
VB6 (or earlier): option explicit
VB.NET: option explicit
VB.NET (continued): option strict
Reason: It may seem nonsensical at first sight, but it really helps writing clean, understandable and nearly bugfree code, just try it, you'll see eventually.

All in all, all of that seems to make sense in any language I ever encountered.

Oh, and I like CamelCasing a lot, but of course your mileage may vary.

The basic premis is a bit lame. KEANU REEVES is or isn't the same as Keanu Reeves. Why should it be so? In the right context, your vastly more powerful brain looks at the sentence and decides maybe it's not really an error that counts, and so ignores it. It doesn't mean it's correct, and wRitiNG tHIngS lIKe tHIs doesn't make them right either. Coders aren't the best linguists so maybe the distinction is lost on the crowd.

I won't comment on script languages that allow you to use a variable without at least saying
var x;
being explicit allows the computer to help you and anyone reading the code.

However, for "SignOn" != "signon" .. blame the coder (unless the tools are deficient).

Newer languages have case insensitive string comparisons, and if you just say string.compare(abc, xyz) and don't care what kind of compare it uses, and it doens't work when your user is in Malta, and you didn't write any unit tests then maybe it's a shame on you. (hey nobody's perfect)

Like rolfehub (and others) say, sticking to convention is better and will save your butt, regardless if your compiler thinks of foo and FoO as the same thing. Code is meant to be read by humans.

Linux SHOULD be blamed for being case-sensitive.

Differentiating between variables using case alone is a retarded idea. All the people who advocate disciplined coding ought be shouting loudest that this is a RETARDED IDEA.

Using all lower-case or all upper-case is also a bad idea. Using varied case adds meaning and emphasis to identifiers, whether in C# or in filenames.

What ends up happening is that I use upper-case identifiers for clarity, and then give myself carpel-tunnel enforcing that choice everytime i use the identifier (programming or typing in the terminal).

The best solution is what's used in VB.net in VS. You declare an identifier the way you'd like it to look, and then the IDE automatically fixes the capitalization after you do the typing all lowercase.

I'm thinking there's gotta be a plugin that'll do the same for C#.... If anyone knows one, let me know!

As far as I can tell, when I'm developing on Linux, case sensitivity is rarely an issue it all. It improves readability, but doesn't hurt writability, thanks to near-universal autocomplete, both in text editors and shells.

I have to agree with an earlier poster that a case-sensitive language should NEVER allow two identifiers in the same scope that differ only in capitalization. I wish python had that rule, it would solve a lot of problems.

I do see one drawback to case-insensitive languages, though. They allow a programmer to do stuff like this:

for (fred = 1; FRed < 100; FRED++) {
wiLMa = frED * 30 + barNEy;
}

which should result in said programmer being immediately shot.

Lloyd, I'll be sure to add that to my list of approximately 1.2 billion reasons programmers should be immediately shot. ;)

I agree that differentiating variables by case is a stupid, stupid idea and that case-sensitivity has its roots in keeping compilers simple (and performing well) back in the olden days, but I think case insensitivity is the wrong answer. Sure, Visual Studio will correct inconsistent casing, but do we really want to put this burden on the IDE?

The compiler should deal with this for us. I vote for a case-sensitive language that considers it a compilation error to declare two variables which differ only by casing. At the very least, a warning. This would be pretty much the same thing as having a case-insensitive language where it's a compilation error to use a casing not consistent with the original one. I suppose some may argue that this will affect productivity in scripting languages, but we can also work the VS auto-case-correcting behavior into the picture.

I think this is a much better solution to this problem than case insensitivity.

Case sensitivity is just something that I learned to live with thirty odd years ago, and I don't really think about it.

My personal bugbear is meaningful variable names. Criticizing other people's code is easy. You need to have been coding for a few years, leave one of your own programs and then come back to it to realize how frustrating variable names like "num", "total" and "max" are.

What has that to do with case sensitivity? Well, whether or no the language is case sensitive, I am still going to use camelCaps and have variable names like "numberOfWidgets", "maxAllowableBadWidgets" and the like (I don't like underscores, like "number_of_widgets").

So, my variable names are either cut and pasted, or autocompleted by my IDE as I type them. I don't make case-sensitivity errors because of this.

And for those complaining about interpreted languages like PHP, Zend offers an "analyse code" option on the right-click pop-up menu; I can't speak for other IDEs, though.

Yes, I guess that case sensitivity is a religious thing, but it goes right past me because of the way that I code.

I've been programming for 16 years in C and C++. More recently I have been using Java and C#.

The case sensitivity of these languages have never bothered me. I don't see why so many are making such a big deal about it.

The way I see it if you spent as much time actually coding instead of writing long posts complaining about this you would have achieved a whole lot more.

I think case sensitivity makes sense because it makes things read easily, and not look like balls - which, in general, aren't we supposed to be writing code that is easier to understand than it is to write?

Case sensitivity is a useful feature because it forces you to call an object the same name, not so you can have ten objects in the same scope named htmlTag, HTMLTAG, HtMlTag, and whatever other leet garbage you can think of. It's so someone can glance at your code and have a nice visual reference to HtmlTag everywhere it is referenced, as exactly the same object.

As for your English example, yes, you can capitalize or not random words in a sentence... but it is poor grammar, makes it harder to read, and looks less professional.

I mean, my name is Mike - the naming convention on proper nouns in English is to capitalize all proper nouns. If you write mike or mIke or MIKE I can figure out about whom you are talking... but you'll look like a twelve year old on IRC.

Case-insensitive languages, by not forcing you into "correct" grammar, lead to sloppy code that is harder to read because there is no consistency. At the very least, they should give a warning or something when you compile so that cleaning it up is easy.

Case insensitivity is downright dangerous in scripting languages where you don't have to declare or assign values to names before you use them. The language I use will return nil for any unassigned variable name. Also, nil is equivalent to false in "if" statements. This causes some problems. e.g.,

DoIt = foo(blah)
if Doit then
bar()
end

Doit will be nil and bar will not be called. Worse, there won't be a warning or an error. How to fix this? Make the compiler/interpreter warn if two variables that differ only by case ever exist in the same scope.

Your claim that this is a 'religious' issue is just a total cop-out so you don't ever have to listen to anyone else's counterpoint.

You don't really care about the reasons why we have *ALWAYS* used case sensitivity, you just want to be lazy in your coding, and think that EVERYTHING else should change to suit yourself.

You also blithely assume that english is the only language that matters here because it is what YOU write YOUR programs in. Does case insensitivity make sense at all for other languages?

The argument that keywords are in english while identifers and such will be in a different language is baseless, because keywords are almost ALWAYS CASE INSENSITIVE ANYWAY.

Should we change everything thats already in existence now because you want to be lazier and you keep typing your identifiers with the wrong case?

Your main claim for what makes "case sensitivity bad" is totally weak. You spend a lot of time typing inconsistently, and it is somehow the languages fault?

I have never spent an entire afternoon bashing my head against the wall sorting out a typo. case based or misplaced letters. I am far more liekly to misplace letters than screw up casing.

If you spent more than 15 minutes trying to sort out a typo bug, The issue here is your debugging ability, not your typing. Learn how to better spot problems in your code.

HtmlTag and HTMLTag look completely different, yes if you said them out-loud like spoken english, they would seem the same
But who SPEAKS OUT PROGRAMMING CODE LIKE SPOKEN ENGLISH?
I sure don't, I *read* my code, and HtmlTag and HTMLTag look completely different to the eye, what they sound like to the ear is completely useless in the case of written words.

Case-insensitive languages do NOT "lead to sloppy code". The example given above is defective. In a case-insensitive language, "DoIt" and "Doit" are the same, so the program runs correctly. It's only in a case-sensitive language that the given example fails (and takes extra debugging time). Smart editors in case-insensitive languages automatically convert all occurrences of an object name to be the same case throughout so there is no confusion or loss of readability.

It's not just a scripting language vs compiled language issue and Intellisense isn't available in all languages, editors, IDEs, etc, so it's not a solution. Even if Intellisense were universally available in program editors, it's not a replacement for case-insensitivity. Intellisense is a useful enhancement that does make the programmers job easier and less case-sensitive.

Not only should programming languages be case-insensitive, but so should the programs written in them. Since it's obvious from this discussion that you can't even get a fairly small group of programmers to agree about case in a programming language, imagine what it's like for 1 billion users using 50,000 different programs written in 20 programming languages by 200,000 programmers favoring their own version of case-sensitivity. It's insane. One of the problems of having case sensitive development tools is that it encourages programmers to write case-sensitive applications because that's what they're used to. They don't think about the impact that has on user productivity and training time.

At the risk of offending someone, I offer one of my signature/tag lines: "Case sensitive applications are written by programmers who are too arrogant, too lazy, or too stupid to understand that without users they wouldn't have a job."

That's not to say that case-sensitivity has no place, case-sensitivity does have it's place, but it should NEVER be the default behaviour. The default should always be case-insensitive and case-preserving with the ability to force case-sensitivity and/or case conversion when it's appropriate.

Identifiers differentiated only by case are a bad idea. True, there are some in human written languages, but there is no equivalent in spoken languages (at least not the ones with which I'm familiar), so case isn't the only distinguishing factor, context is more important. Human languages are very tolerant of improper case, so contending that human languages are case-sensitive is a straw argument. "rome wan't built in a Day" is improper, but perfectly understandable.

US vs. us is an improper comparison, U.S. is the proper abreviation for the United States. He or Him vs. he or him does have a different connotation, but it can generally be inferred from the context, thus the case becomes inconsequential. I could give many more examples, and I'm sure someone will point out an example or two where case is important. However, that simply supports my assertion that case-insensitivity should be the default and case-sensitivity should be used only when required.

The real point of this whole discussion is that we have to start making computers adapt to humans rather than making the humans adapt to computers. Case-insensitivity is one adaption that is fairly trivial to implement and it's time that it becomes the standard rather than the exception.

Well, funny I've never come across a bug related to case sensitivity !
I even find it easier to read initNightRunRun1 than initnightrunrun1, don't you ?
I'd even be happy to have the langage force me use initNightRunRun1 everywhere after I've defined it !
Force me to write readable code ! I like it.

I rather prefer case-sensitive languages (like C#). The casing of a variable denotes the access of the variable-private or public. That way, I can declare a private field, htmlTag, and give it access with a corresponding public property, HtmlTag. At a glance, anyone reading my code can instantly tell what access level anything is. With a case -insensitive language, you can't do this; you'd have to name the private field something else.

As far as case-sensitive languages generating errors, a good IDE will take care of that with autocomplete. Using C#, Visual Studio suggests the correct variable when I start typing it, no matter the casing I use: upper, lower, mixed, or the correct casing.

While case-sensitive languages ALLOW you to declare HtmlTag, htmlTag, hTmLtAg, HtMlTaG, HTmlTAg, htMLtaG, HTMLtag, htmlTAG, etc. all in the same class, procedure, or whatever, that is really bad style, and should also be added to Jeff's list of approximately 1.2 billion reasons programmers should be immediately shot. That's why naming conventions should be followed. Heck, naming conventions make case-insensitive languages more readable.

Anyway, like Jeff said, this is a religious issue. And I'm not a missionary looking to convert anyone. I'm just saying that case sensitive is better. ;)

A language can still force you to write (more) readable code while remaining case-insensitive. Many development environments do in fact convert every instance of a variable name to appear in the same case (either the was it was defined or the way it was last entered). My preference is that my editor/IDE convert a variable name to the same case I used when I defined it, and that it use some form of auto-complete to simplify my coding, however, none of that requires case-sensitivity, only case-preservation.

In fact, an editor that does that conversion for IS in fact case-insensitive, so anyone arguing that such editors are a reason to continue case-sensitivity are completely missing the point. The very tool they're using to explain why case-sensitity isn't a problem operates in a case-insensitive manner to ease the difficulty of dealing with case-sensitive languages. That simply just supports my assertion that case-sensitivity is a problem and that case-insensitvity should be the default behavior.

I'll assert it again, case-insensitive and case-preserving should be the default and case-sensitity and/or case converting (all upper, all lower, or "proper" case) should be options that are used only when appropriate and/or required.

P.S. If you wish to contact me about this, you can do so using my first name and last initial at otcnetworks.com

It's funny that lots of people talk about how case insensitivity mean that lazy programmers can make the code more unreadable.

I was under the assumption that laziness was a virtue for programmers.

My own brand of laziness with case insensitivity is to use case to denote the scope of variables, and give them all exactly the same name. You can do this with prefixes too. I just find it nice and easy to do with different cases.

.... boy did you ever draw up the wrong analogy.

if it is such a problem for you, then just use lower case, or teach yourself to be consistent, a good quality in any developer..

years of using python and case sensitivity is never a problem for me, were you schooled in VB?

programming is about efficiency right? how about using case for scoping? for class names? for the globals you probably use if your from a VB background,

I am strongly in favor of case insensitivity. I grew up on Fortran and Pascal in the 1970s and 80s. (Both case insensitive languages.) Back then I borrowed the style of "CamelCasing" from various systems (such as CMU's Scribe system.) I found mixed case improved my speed in both reading and writing code. Even VAX assembly language was not case sensitive.

Now I don't know if its a form of dyslexia or not, but I have found working with all lower case languages tend to slow my visual processing of computer code. (Not to mention C and its heavy use of punctuation like slashes and back-slashes.) When I mix my case I work faster, easier, and more accurately.

Remember, C was not intended to be a high-level programming language. It was meant to be an alternative to assembly language for writing operating system components. The original C case sensitivity was meant to allow for a distinction between a procedure and a related compile time "macro" for the procedure. This distinction in no longer needed in C as a high level language.

But, we are now stuck with C and its derivative languages and the poor design choices made decades ago.

***
I've been programming for 16 years in C and C++. More recently I have been using Java and C#.

The case sensitivity of these languages have never bothered me. I don't see why so many are making such a big deal about it.

The way I see it if you spent as much time actually coding instead of writing long posts complaining about this you would have achieved a whole lot more.
John on April 8, 2007 10:18 PM
***

And I have never found a building with only stairs to be a problem for me, but I CAN see how it would to someone that is handicapped.

Maybe its dyslexia, or some other reading/writing disorder, but when I mix my case I can visually process the code much better. Maybe I am alone in this problem, or maybe there are others that simple struggle with it in silence.

I think case sensativity in programming languages, and especially file systems, was one of the biggest mistakes in computer history.

Hi Jeff, you may or may not agree with the response I just posted on my blog, but I've got evidence that case sensitivity can be good. :-)

http://blog.micropledge.com/2007/07/the-case-for-case-sensitivity/

One thing no one should doubt is that case-insensitive is better for beginners. It lowers the amount of errors beginners make, and thus lowers the bar of entry.

Look at all the development environments designed with beginners and non-programmers in mind, and they are case-insensitive: pascal, HTML, SQL, logo and its variants, BASIC and its variants including visual basic, etc. Even the creator of python wanted to change python to be case-insensitive, explicitly because it was a source of errors with beginners, but was rebuffed by some existing python users.

That said, people aren't thinking outside of the box here. It is possible to support both. You can have a compiler that is case-sensitive, but uses case-insensitive matching on failure. It's very simple to implement, I've done it for boo, which is _nearly identical_ to python syntax-wise. It can also check for names that vary by naming style (SomeName vs. some_name). That allows people to get away with a lack of creativity in variable naming:

dog = Dog("Rex")

yet still not have to memorize the exact naming style of some method.

Even that isn't thinking outside of the box enough. Again, look at development environments designed for children and non-programmers to see other ideas, such as the graphical building blocks used in lego mindstorms, scratch (http://scratch.mit.edu/), Labview, Yahoo Pipes, and other recent web 2.0 ides.

Doug, I agree.. a compiler should warn the user that there are two similar variables being used with different case. Languages them selves should not permit case sensitivity, for the same reason Ada does not permit it. Unfortunately even Wirth has designed Modula/Oberon to be case sensitive.. worse yet one must type BEGIN and END reserved words in CAPS LOCK.

Correction: I agree with doug about people not thinking outside of the box, I still think case insensitivity is nice, and NewDog or DogCast is better than the more confusing dog and Dog.

The one, and only, situation in which *any* string comparison should be case-sensitive is passwords. The cost of the decision, for example, to make the *nix file system case-sensitive is almost certainly now in the 10s of millions of dollars and increasing every single day. Unacceptably foolish.

Case sensitivity is a Good Thing.

First and foremost, it makes Foo and fOO used for the same variable a debugging issue instead of maintenance by a future coder issue.

Second, in some languages, for example Java, Foo and foo are assumed to mean different things. Foo is normally class name, while foo is variable/method name. In some languages, for example Haskell, that is even compiler enforced. In those languages, letting Foo and foo mean different things is a good thing. For example "public void setFoo(Foo foo)" is a frequent pattern in Java code.

Typos aside, I think this problem pretty much goes away when you come up with a variable naming convention and stick with it.

I've been bitten by similar identifier problems in scripting languages, but to my knowledge, it was never a case thing. It was always something like "varlist" versus "var-list", or changing the name of a variable and missing one accidentally (oops, didn't do a global search and replace.) Caps have never bugged me.

Should be obvious:
One place the case-sensitivity problem can be tackled is in the IDE or editor.
I know this sounds almost off-topic, but how feasible does changing the syntax conventions of languages look when millions of lines of code are running in production use across the world and your new version comes as an upgrade?
IMO, For all practical purposes, we can *do* almost nothing about these time-sinks. Requiring people to readjust their habits and thinking, which they've comfortably lived with for years? It's easier to become Bill Gates.
...
Or is it The System's way of ensuring that we don't reach the best possible language syntax ever? That we constantly keep making mistakes and *then* repairing them when we find them?
All humans, after all...
(PS: Sorry if I didn't read a similar comment above - there's probably a hundred of them...)

Well, probably should not only FooBar, foobar, and FOOBAR be the same thing, but also FOO_BAR and foo-bar?

First, I'd like to point out VisualAssistX to anyone using Visual Studio. If you type pCharacter.gchar it will suggest getChar(). (See shorthand: http://www.wholetomato.com/products/features/members.asp )

Also, I'd like to ask if _anyone_ here would submit code with two different spellings of a variable name and not be embarrassed about it later. (I'm actually curious.)

Jeff, if you had an IDE that told you you spelled 'console' incorrectly, would that make you happy?

And finally, some anecdotal evidence of case-sensitivity being helpful:
A friend of a guy I think I know was maintaining some code. There was a function called diveRunDo. However, since he was using a case-insensitive language, when a coworker called that function but used diverUndo, the compiler didn't complain. So my friend spent hours trying to figure out why the diver's last action wasn't being undone.

So that's not true, but I can imagine many such problems.

> Case sensitivity lets the worst instincts of developers run wild.
I would say that lax rules let the worst instincts run wild. Really, instead of case insensitivity, a better solution would be something like what Maciek suggested: The compiler complains when you use variables that only differ by case.

I see enough spelling mistakes in comments (even though VS highlights them), I don't need to see them in variables. ANd don'T improper CAPITALs bother yoU?

-David

i'll actually often use the same name with different capitalisation for multiple things. Most notably classes and variables which hold instantiations of those classes.

For example, in Javascript:
function Client() { }
(yes, this is how you make a class in JS)

var client = new Client();

because I always use UpperCamelCase for classes and lowerCamelCase for variables, I don't have to resort to vUsing adjHungarian nNotation, or my other favourite method when not using a case-sensitive language:
var myClient = new Client(); // or,
var theClient = new Client();

Writing KEANU REEVES in english rather than Keanu Reeves is just as incorrect a use of the language as cap mistakes are in C. The difference is that the compiler for the english language (or any other human language), the human mind, is insanely much more powerful than any compiler for a computer language, and thus can figure such ambiguities out, just as it can decode spelling mistakes, incorrect grammar, understand accents when compiling spoken languages etc. This doesn't mean that it's right to type kEanu ReeVes, just that the compiler catches the mistake and corrects it automatically.

[quote]
Writing KEANU REEVES in english rather than Keanu Reeves is just as incorrect a use of the language as cap mistakes are in C. The difference is that the compiler for the english language (or any other human language), the human mind, is insanely much more powerful than any compiler for a computer language, and thus can figure such ambiguities out, just as it can decode spelling mistakes, incorrect grammar, understand accents when compiling spoken languages etc. This doesn't mean that it's right to type kEanu ReeVes, just that the compiler catches the mistake and corrects it automatically.
[/quote]

http://rx-review.com/
perfect generics - http://perfectgenerics.info/

I read through most of the above posts...

What surprised me with this particular example:

'I spend an hour today debugging a possible problem only to notice that "SignOn" != "Signon".'

Is that any decent tool would alert the coder to his mistake unless he had used both SignOn and Signon as variable names, in which case, thats the programmer's own fault for using variables with similar names. Certainly should not have taken an hour to notice...

As much as case sensitivity causes a problem it can at least be worked around with a good compiler/interpreter. I totally agree that any new language should not be case sensitive though... I struggle to think of any reasons why that is a good feature for the user, it just makes things easier on the developer /sometimes/... after all, almost every major language comes with some kind of case-insensitive comparison in its libraries (even the notoriously unfriendly C++ has "stricmp" and friends).

In my opinion case sensitive source code is (much) better because it is easier to read.
Having the same identifier always written with the same 'casing shape' helps me to spot its repetitions in a page of code quickly: actually spotting the shape of the word before I even read it.
I find it takes longer to read code if the casing always changes.

Look at

theNumber += 3;
THENUMBER = thenumber / 2;
TheNumBer = function(THENUMBER);

And

theNumber += 3;
theNumber = theNumber / 2;
theNumber = function(theNumber);

In the second example it's more obvious to me that just one variable is involved in the computation.

Case sensitivity is useful in the same way as indenting, aligning and using blank lines might be: it helps readability (not as much as correct indentation of course).

Of course writing in a case sensitive language takes (a little bit) more time but since we read source code more often than we write it I believe it is a performance improvement after all and I like it enforced by the compiler.

So you wanted a real world example in regard with case sensitivity being helpful rather than just spoiling all the fun?
Well, here's one. Imagine that there's some Matrix class:

class Matrix
{
//... more stuff here...
public:
void printOnScreen() const;
private:
size_t x, y; // <-- attention!
std::vector<int> cellVec;
};

//- simple printing to console (with formating)
void Matrix::printOnScreen() const
{
//- now look at the loop variables...
for(size_t Y = 0; Y<y; ++Y) {
for(size_t X = 0; X<x; ++X) {
std::cout<<cellVec[X+Y*x];
}
std::cout<<std::endl;
}
}

It's clearly seen to me that in this context Y != y && X != x
They are not the same. What would you propose in a case insensitive environment?
1. using "size_t _x" or "size_t x_" or "size_t xx" or whatever as loop variables?
2. using "this->x" and "this->y"?
3. renaming class members to free "x" and "y" identifiers for loop usage?
4. your solution here...

I'd say that anything would be less readable than the example above.
But it's just me...

The company I work for has a procedure in place where any code changed by one developer must be checked by another. This is normally done by comparing the code before changes to the code after changes using a diff tool. VB, with it's code insensitivity, drives me insane everytime I have to do one of these comparisons. There's always a bunch of variables that have changed case (usually because the developer accidently changed the case of one instance and the IDE decided to help out and changed the rest).

Now, I could change the diff tool to ignore case, but then strings presented to the user may have changed, so users end up with badly Capitalised sentences (which drives my manager insane). So, VB's case insensitivity is a right PITA, which C# gives me no problems at all.

I think his whole whining about case sensitivity is pretty silly.
As for scripting, people are not more prone to "mis-case" a name string than mis-spell it in other fashions, especially if he or she adhers to sound naming conventions, like "all english words in a name start with an uppercase letter".
So you could argue that not only case sensitivity should go, but also any sort of precise spelling. Yeah, let the compiler guess what is closes to the declared names, right? Would be so cool.
No it woulnd't, it would be ambiguous shite, just like case insensitivity.
I think we should not revert our languages to pre-stoneage behaviour, especially not for such silly reasons.

How about this:

1) demand programmers/scripters to adhere to sound naming conventions (consistent inside company)

2) use tools to check every script's strings against the declarations for ANY sort of misspelling. If there's a string found that's not declared, this is a syntax error !
The fact that scripting works so much with strings to call things makes these into somewhat of a language feature that should be checked by the language for correctness...
If no such language or external tools are available, make them yourself, damn it, it's a piece of cake.

I prefer my compiler to not attempt to mangle isLand() to Island() or vice versa, depending on which declaration came first, thank you very much. And using a camel naming convention without underscores makes me more efficient, because it helps wrong things to look wrong, just like Apps Hungarian notation does, so I will spot them early and fix them early. And even if I do fail to spot the problems, the compiler will barf on it instead of silently incorporating the problem into the runtime, making for an earlier failure (which is also a Good Thing). Sure, I could circumvent this by not using case, but rather underscores and whatnot, but case is in my opinion better precisely because it's natural: I can identify/separate words based on capitalization faster than I can spot underscoring differences, and I still see them as a single block of text and not several pieces connected by something else.

In any case, whatever your preferences may be: you're just a short lowercasing/case-translating script away from following your own conventions regardless of the compiler's/interpreter's needs, so there's no need to be aggressive about it.

For speed I usually cut n' paste identifers in C++/.net/Java so very rarely do I ever have case sensitivity problems - and anytime i do I get compiler errors. Parsed languages will catch most such errors unless they decide to define/allocate a misspelled varaible as a new one and use it wihtout warning, review your choice of coding language if this is problem. Humans are sloppy granted - and should be allowed some slack, but programming should still be a matter of precision so I see no major reason why case-sensitivity should degrade coding efficiency unless one is being ruthlessly sloppy.

You'll be happier to read neat consistent, properly indented, spaced and commented code (with hungarian notation or similar) rather than a mess of mixed casing and multiple naming paradigms.

Finally if you have time to worry about case-sensitivity vs coding efficiency then obviously more important things like your software design and algorithm efficiency must be impeccable. Otherwise worry about that first!

Of course we need case sensitive languages. Those stupid case insensitive languages don't leave me enough namespace for variable names and are too restrictive!

Case sensitive languages let you powerful things like have the variables myCow, MYCOW, mYcow, and mycow all in the same scope with different types.

Case closed! On to Hungarian notation....

"In my opinion case sensitive source code is (much) better because it is easier to read. Having the same identifier always written with the same 'casing shape' helps me to spot its repetitions in a page of code quickly: actually spotting the shape of the word before I even read it."

My IDE (VS.NE) automatically fixes the case in my code to match the declaration at dev time and I get the same benefit.

I guess it is like those woodworkers who insist on chiseling their own mortises, it might not be as clean, but at least it takes twice as long!

I like the isLand() - Island() comparison. Also, here's one adapted from an episode of Squidbillies...

Therapist - theRapist

Hmm. Perhaps case sensitivity is a good thing after all. I wouldn't want to get those two confused.

"Well, funny I've never come across a bug related to case sensitivity !
I even find it easier to read initNightRunRun1 than initnightrunrun1, don't you ?
I'd even be happy to have the language force me use initNightRunRun1 everywhere after I've defined it !"

If C# were case insensitive why wouldn't I still be able to use 'initNightRunRun1' ? And in the IDE, if we tried to type initnightrunrun1 after the original 'initNightRunRun1' was used then intellisense should correct it. So, I agree that the IDE should help keep the variable names pretty and enforce only one version ( case combination ) of that variable name. And why not add that as an option to Visual Studio ? What could it hurt ?

But why oh why does it allow something like the following ?

foreach (Order order in orders)

When I see this it makes me cringe. Talk about sloppy coding. If you're insistent on using the name 'order' in the first two variables then why not prefix it with something meaningful instead of using case ?

I like case sensative. We use lowercase to denote private variables and uppercase to denote public ones. Makes it a lot easier to keep track of things without having to modify the names themselves.

I love case sensitivity.

I do.

I'm not agree with it that case insensitivity is a much more human being friendly design choice. I think that case insensitivity is NOT much more human friendly design choice. I wrote about this in my friend's blog on http://detoxmed.com. I think that's be useful.

@Kris: "We use lowercase to denote private variables and uppercase to denote public ones."
But you can still do that, even in a case insensitive language. You just can't use the same word. Which isn't particularly valuable in the first place.

As for Python and case sensivity - that's why we all have that nice autocompletion feature in our code editors.

I usually only write a word completly once, all the rest instances are autocompleted after first 3-4 letters I write. When I misspelled these first letters something wrong or nothing at all will show instead, so I will notice this.

Autocompletion is IMHO the single most important text editor feature, even more important than syntax higlighting.

PS. when writing graphic/physic code in C++ I often name my variables X,Y,Z when refering to world coordinates, and x,y,z when refering to object coordinates, it also aplies to other short names mostly used in numerical algorithms. I can't persuade myself to use normal camelCase convention there, it would make my nice equation 4 time as long, and I would have to break it into many lines. It's like in math - differenting variables by case is sometimes useful, mainly when there is some constant relation between every big and small case variable.

Many posters are still confusing case sensitivity with case preservation, they are NOT the same thing. Case preserving means that something kept using the capitalization as it was typed. Case insensitive means that case is not relevant when comparing a string (e.g. a variable name, class name, etc).

In a case preserving system, you can use CamelCasing (or camelCasing), if the system is case insensitive, then "Foo"="foo", but in a case sensitive system "Foo" != "foo".

People read mixed case text faster and more accurately than all upper or all lower case, there have been numerous studies that demonstrate that (you can google them if you want). This alone is a very strong reason for case preservation. Case preservation also provides clarity, "ExpertsExchange" clearly has a different connotation to the reader than "ExpertSexChange" and either is much clearer than "expertsexchange". Case preservation is a great thing, I'm very much in favor it of.

Using only case to differentiate variable scoping is absolutely unacceptable. I don't have as big an objection to using it to distinguish an instance vs. a class, but I do think it's a poor practice.

As I mentioned in a previous post, case sensitivity is sometimes necessary and appropriate, however, I'm opposed to case sensitivity in most instances.

In fact, for clarity, I'm going to stop using the terms "case sensitive" and "case insensitive" and start using "case dependent" and "case independent".

Variable, class, function, procedure names should not be case dependent. Program names, command line parameters, and program input should not be case dependent, EXCEPT when necessary and appropriate.

In a well designed case preserving, case independent system with an editor that provides auto-completion, you get the best of both. All variable/function/procedure/class name is converted so that all instances have the same case. It is preferable that all instances are converted to use the case used when the object was declared or defined, that way the developer only has to worry about getting the case correct one time, and all other instances will be converted to match that one.

The only thing you can't do in that environment is use ONLY case to differentiate the scope (or differentiate between an instance and a class). For instance, you can't use "var client = new Client" You can still use case to differentiate a class, instance, or scope, but you can't use ONLY case. For example, you can use "var curClient = new Client". You can also use Hungarian notation.

This allows for writing very readable code that is more maintainable by another developer. It also creates code that is portable to another system/language while minimizing the problems of different variable scoping rules, syntax differences, etc.

Code is read more than it is written.
And a case sensitive language forces you preserve the case.
A variable named greenHorse is more readable than GREENHORSE,greenhorse or GrEeNhOrSe,...

And while I know you can just use case preservation in a case insensitive language, it is my experience that unless it is enforced(like with a case sensitive language) People just won't do it.

PS. the argument that an IDE like VisualStudio will autocorrect case preservation in a language like VB.NET is void, since it will also autocomplete case sensitive variables in C#/C++. thereby avoiding the differentCaseDebuggingProblem.

IMHO case sensitivity should not matter to the programmer. I believe it is part of good coding style to type identifiers in a consistent manner whether or not the language in question is case-aware.

Would you really feel happy with a code block that refers to both FOOBar and fooBaR?

I got into the habit of assuming that the language I'm writing in is case sensitive. I only recently realized that PHP's functions are not case sensitive! I can't remember the last time that I actually had an error because of case sensitivity, it has become a way of coding for me.

People who like case insensitive languages are just lazy.

How is cabbage equal to CABBAGE atall? Doesn't make sense!

As a PL/SQL programmer I can say that

v_person_name = V_PERSON_NAME

but

'Smith' <> 'smith'.

Variables need to be parsed only at compile time, so no worries for tiny performance penalties there. Person names, OTOH, need to be compared millions of times a day. So you trim every fraction of a second where you can.

Many years on and this argument still hasn't been settled... I doubt it ever will be but here is my 5c worth (cos our government stopped making 2c a long time ago):

Using case sensitivity to refer to different variables is just plain stupid. I program primarily in C# but the only time I (or anybody I have ever worked with) make use of differing case to name things is in the case of a property and it's backing store; after all, they are two different ways to expose the same data (external and internal respectively, when used properly). That gives a clear indication that they are related without having to add on wasteful prefixes.

I agree with Wayne Kroots, casing is simply a matter of style, the consistency of which should not depend on the language. Do whatever makes the code more readable, even if that means maintaining proper casing in languages like VB.

As for Scott Hanselman's case, it is unclear if his problem was casing of the variables themselves or the string values they represented. Any language should be able to perform both case sensitive and insensitive string comparisons, it's up the programmer to decide when and how to use which.

Finally, to Jeff Atwood, you kept saying you were only able to find documented cases of case sensitivity hindering developer performance. Something all of us as programmers should be aware of (based solely on user feedback if nothing else) is that people are quick to complain when something doesn't work the way they expected, but much (much, much, much, muuuuuuuuuuuuuuuuuch) slower to praise when it does. With that in mind, don't expect people to blog about how case sensitivity just saved them hours of debugging (most programmers will either go home early or find something else to code).

Ph03n1X
Glorified Typist
Earth

P.S. Got tired of reading all the comments so I stopped after about 30 and jumped to the bottom, I'm very sorry if I've repeated anything said before ;)

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

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize

call 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?

I can't believe I just read two years worth of comments saying that case insensitivity leads to hard to read code. Just because a language is not case sensitive, doesn't mean that it won't let you use variables with a casing convention that conveys meaning.

Case preservation is what creates readable code, not case sensitivity. I write VB.Net every day and we have strict case conventions. We catch violations through code reviews just like everyone else does. Writing in C# doesn't automatically cause developers to adhere to sane case conventions.

There is no case, other than using case to distinguish between variables, where an identical casing convention cannot be followed in a case insensitive language. You can write C# in all lowercase if that floats your boat (except for calls to the framework). You'd be just as much of an idiot to do it in C# as VB.

Let me repeat -- the only case where case sensitivity has an actual end-effect is the where two variables are distinguished only by case. Since this is a practice not recommended by Microsoft, there is actually no likely case where there will be a functional difference. Also, since VB is case-preserving, there is no case convention that is not allowed or not preserved (other than the affore mentioned not recommended practice).

The only difference is that a case typo is auto-fixed in the VB IDE and caught by the compiler in C#. If you make a legitimate typing mistake in either language, it won't compile. Learn ctrl-space and you will never make either a casing or a typing mistake. The only reason case insensitivity hasn't been removed from modern compiled languages is that is pretty much doesn't matter any more. Since case sensitivity has traditionally been there in C type languages and removing it will cause a lot of code to not be directly reusable, the minimal costs of changing it outweigh the almost unmeasurably small benefits of getting rid of it.

it makes no sense.
but yes, I guess it is a religious issue as the comments I am getting here http://stackoverflow.com/questions/895423/case-sensitive-vs-insensitive-syntax are not to the point, but with lots of emotions.

What is needed is case CONSISTENCY.

Give me a call about your C/PHP/Python program and I tell you by voice why case-sensitivity is a BAD-THING. I don't speak in case!

"You need to change your code to CasE, upper-C, lower-a,
lower-s, upper-E".

Case conventions are useful but not for distinguishing namespaces. Namespace checks should be done in a case-insensitive way so I can't have camelCase, CAMELCASE, camelcase, Camelcase all having different semantic uses.