programming and human factors
by Jeff Atwood
One of the most pernicious problems with C-based languages is that they're case-sensitive. While this decision may have made sense in 1972 when the language was created, one wonders why the sins of Kernighan and Ritchie have been blindly perpetuated for the last thirty-three years.
I realize this is a religious issue. I'm not attempting to change anyone's mind. I'm merely voicing my discontent with the status quo. Thirty plus years later, does case sensitivity still make sense? Julian at OddThinking makes a compelling argument that it doesn't in The Case for Case-Preserving, Case-Insensitivity:
Suppose I declare that "KEANU REEVES interferes with elephants.". Can I claim that I was not libelling the wooden Hollywood actor, purely because I spelt his name in all-caps? Can I claim to a judge that KEANU REEVES was a undeclared identifier and therefore the entire statement was semantically meaningless? Of course not. The English language is flexible enough to recognise that "KEANU" and "Keanu" are the same name. Even mail addressed to "KeAnU rEeVeS" will be delivered to the correct person.If a computer can also disambiguate this accurately, it should do so too. If the software fails to adapt to the similarity of upper- and lower-case, it leads to frustration.
For me, an example of this frustration appears in both Python and PHP. Each of them have the same killer combination: they are case-sensitive with identifiers, but they are scripting language that do not resolve identifiers at parse-time. I consistently fall for the same traps. A distressingly large percentage of my debugging time is spent correcting mistyped identifiers - often not detected until several minutes into a test run. The most common mistyping I make is incorrect capitalisation. Of those, the two most common capitalisation errors I make are: HOlding DOwn THe SHift KEy TOo LOng, and being inconsistent in CamelCasing the term "fileName" (I never did resolve satisfactorily whether it was one word or two!)
However you feel about case sensitivity, the bottom line has to be this: does it cost you productivity? The answer is undeniably yes, as Scott Hanselman notes:
I spend an hour today debugging a possible problem only to notice that "SignOn" != "Signon".If I had a nickel for every time Case-Sensitivity or Case-Insensitivity bit me, I'd have like seven or eight bucks. Seriously.
Moral: Know if whatever you're working on cares about Case, and if it does, make a Post-It to remind you and stick it to your monitor.
There's nothing we can do about existing tools and languages that are case sensitive, but we can make sure we don't perpetuate past mistakes. Unless you have extremely compelling reasons to make something case-sensitive, case insensitivity is a much more human being friendly design choice. Designing software that's easier for machines is questionable at best.
The two languages stated are both dynamic languages. Case sensitivity has no buisiness in a dynamic language in my opinion.
Brian Russell on December 5, 2005 1:27 AMI 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?
mike on December 5, 2005 1:40 AM"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?
matt on December 5, 2005 1:41 AMUse a good compiled language instead... ;-)
Jeff Lewis on December 5, 2005 2:46 AMI 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...
matt on December 5, 2005 3:26 AM"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.
Kartik Agaram on December 5, 2005 3:37 AM"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...
Kyle Bennett on December 5, 2005 3:44 AMWere 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?
Jeff Atwood on December 5, 2005 4:02 AMSo 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?
Jeff Atwood on December 5, 2005 4:07 AMWait 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.
matt on December 5, 2005 4:15 AMIf I came across code in source control that used inconsistent casing in a language that allowed it, I'd fix it.
David Grant on December 5, 2005 4:16 AM"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.
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..
Jeff Atwood on December 5, 2005 4:34 AM"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"?
matt on December 5, 2005 4:42 AM"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".
matt on December 5, 2005 4:44 AM"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.
Scott on December 5, 2005 5:23 AMI'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.
brad on December 5, 2005 5:34 AMApparently, 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.
Jeff Atwood on December 5, 2005 5:35 AMWhich 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.
matt on December 5, 2005 5:48 AM"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.
Scott on December 5, 2005 6:01 AMArgh, 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.
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 Avraamides on December 5, 2005 6:45 AMDavid 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
MOz on December 5, 2005 6:58 AMAs 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.
Jeff Atwood on December 5, 2005 7:13 AMIn 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.
Jeff Atwood on December 5, 2005 7:22 AMBut 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.
matt on December 5, 2005 10:16 AMNow 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
Shawn Oster on December 5, 2005 11:48 AMI 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.
Helen on December 6, 2005 1:04 AM"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?
matt on December 6, 2005 1:23 AMAnd 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.
matt on December 6, 2005 1:27 AMOne 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.
Kurumi on December 6, 2005 1:29 AMCan 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.
brad on December 6, 2005 1:32 AMIn 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.
marcus on December 6, 2005 1:39 AMI 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=638387messageID=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?
--
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.
Marty Thompson on December 6, 2005 2:06 AMFor 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.
Jeff Atwood on December 6, 2005 3:18 AMIt 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"?
Jeff Atwood on December 6, 2005 3:21 AM"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?
matt on December 6, 2005 3:28 AMI 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
Jeff Atwood on December 6, 2005 4:33 AMIn 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.
brad on December 6, 2005 5:52 AMSo 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.
Scott on December 6, 2005 6:23 AMYeah, 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.
Dave T. on December 6, 2005 6:56 AMThe ***** (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'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...
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.
matt on December 6, 2005 9:11 AMAll 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
JOOST on December 6, 2005 9:28 AMI 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.
Gary on December 6, 2005 10:54 AM1) 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?
VBMan on December 6, 2005 12:51 PMthe 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'm curious where VB.NET fits into the defintion of "scripting languages."
mike on December 6, 2005 12:59 PMThanks 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.
matt on December 7, 2005 2:27 AMiYou 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". ;)
matt on December 7, 2005 3:30 AMHeh, 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 ;)
Jeff Atwood on December 7, 2005 4:13 AMAs 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!
Joe on December 7, 2005 4:59 AM
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 on December 7, 2005 11:15 AMJoost,
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."
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).
Damien Katz on December 10, 2005 11:22 AMOld 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.
Bill on December 11, 2005 10:54 AMThe 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 ?
Shane on March 30, 2006 3:29 AMI'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.
rolfhub on April 3, 2006 1:37 PMThe 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.
AC on September 6, 2006 7:22 AMLinux 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!
alex dubinsky on February 10, 2007 11:42 AMAs 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.
AdamG on March 8, 2007 6:03 AMI 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.
Maciek Sakrejda on March 20, 2007 3:36 AMCase 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.
graham on March 20, 2007 8:02 AMI 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.
A. Lloyd Flanagan on March 20, 2007 1:09 PMLloyd, I'll be sure to add that to my list of approximately 1.2 billion reasons programmers should be immediately shot. ;)
Jeff Atwood on March 20, 2007 1:18 PMI'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.
Mike on April 22, 2007 8:54 AMCase 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.
Brendan Dowling on April 30, 2007 12:56 PMYour 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.
Geoff Strickler on May 15, 2007 8:59 AMWell, 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. ;)
Brian Friesen on May 16, 2007 6:27 AMA 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.
Tom Finnigan on May 31, 2007 9:13 AM.... 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,
sh on June 4, 2007 10:11 AMI 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.
Henry on July 9, 2007 7:00 AM***
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.
Henry on July 9, 2007 8:12 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |