views:

348

answers:

7

Can anyone make really a good case ( :-) ) for being case sensitive?

C#: case sensitive VB.NET: not case sensitive C++: case sensitive ...

Worse part: XML which is used inside a language like VB.NET is case sensitive.

I was making the case that it is ridiculous and can only cause harm after we found a bug in our system due to the fact that XML had both Value and value nodes...

I am asked over and over in comments

"Perhaps you can come up with a single argument for why case insensitive is the right choice in such a world?"

Here is an example: I see it analogous to the issue of: URL's should be case sensitive? www.cnn.com <> Www.cNN.com ? Of course they should be the same, ID theft heaven! because humans don't put that much attention to 2 strings that are the same but might have otherwise different casing. Programmers are humans. So getAge() and getage() are the same in most human's minds.


Please notice: I do not think we want the code to actually have a function defined as getAget() and then have code calling it getage(), VS (vb.net) will automatically correct getaget to getAge. So the code is clear and the programmer is aware of the correct capitalization. My point is: good IDE makes the issue non relevant, but it works better in a non case-sesnsetive language like vb.net then lets say c#. Reference: here

A: 

I find case-insensitivity to be just silly. You should follow the capitalization of the original declaration. I can't see any good reasons for not doing so beside being too lazy to type TheRealName instead of therealname.

In fact, I would never even consider using a case-insensitive language.

Zifre
this is hardly a reason that supports a language being case sensitive. so because it is more work (you say otherwise you are lazy) is a reason to say it is good? I thought productivity and less bugs are the goals.
csmba
@csmbe: Is it less work to be case sensitive? That doesn't make sense. You don't get "less bugs" by ignoring the original declaration, you get "less bugs" by *following* it. Do you want a language to automatically correct common typos like "teh" to "the" as well? In the name of "productivity"?
jalf
I don't think this answer contains any constructive information. The arguments presented seem highly subjective. While I agree that case insensitivity invites bugs rather than prevent them, I think it's important to present your opinion in a civil and constructive manner. -1
Lucas Lindström
@jalf: t. Do you want a language to automatically correct common typos like "teh" to "the" as wellactually yes. as million of Word users and outlook users show.
csmba
@csmba: about teh and the, are you joking? If a language made teh and the equivalent, absolutely *nobody* would use it.
Zifre
I didn't say the and teh should be equivalent. Maybe that now we found a source for the perceived gap between our positions. I said that either way, as long as the IDE auto corrects (normalizes) it, it doesn't matter. That is what the vb.net IDE will do, while GetAge and getage are the same, the IDE will normalize and make sure that if the calss.func() was written as GetAge, no matter what you type, the IDE changes it to GetAge. Life Is GooD!
csmba
@csmba: The IDE silently correcting you is even more silly. This is programming, not natural language.
Zifre
+2  A: 
  1. History It is the way it has been done. The XML is VB.NET is case sensitive because the XML standard requires it
  2. Internationalization Are we going to support case in all languages (French, Japanese, Hebrew, Klingon, etc.)?
jrcs3
Klingon is a good example. Different capitalization could change the meaning of the word.
Zifre
@csmba: point 2 is also a good reason against it. It is not contradictory.
Zifre
no, #2 explains why case sensitivity is the right thing. It saves us from having to figure out whether one character is the uppercase version of another. The case rules are awfully complicated, and changing.
jalf
@csmba: I take the second point to mean that different languages treat case differently, and that this should be reognised. Hence, they both support case sensitivity.On point #1, I think we should "learn from our mistakes"! ;)
Lucas Jones
By the way, while very few Klingon programmers exist (which makes the point kinda moot), many Turkish programmers exist, and they have a similar problem (The "Turkish I problem". Google it. It is a common way to test localization)
jalf
+2  A: 

Several case sensitive languages nowadays are that way because the languages they were based on were case sensitive and the transition would be easier. Personally I prefer case sensitive, but Jeff Atwood wrote a pretty good article on why case sensitivity may no longer be necessary.

Brandon
Beat me to the Coding Horror reference!
Lucas Jones
That article is just ridiculous. None of those arguments apply in a static language. Using a dynamic language is just yet another invitation for bugs
Zifre
I must agree with Zifre about that article going nowhere. It concludes that case insensitivity is a productivity killer by quoting nothing more than anecdotal evidence.
ssg
+3  A: 

Slop is never a good idea in a programming language. You want things to be as specific as possible. You never want your language to guess at anything and it should allow as few ways to solve a given problem as possible.

As for a specific answer, how about readability? Doesn't stoRetroData visually differ quite a bit from storeTRodAtA? Not that anyone would do such a thing, but what's the point in allowing it?

I can't come up with any reason to allow ignoring case.

At least that's my opinion--but your mileage may vary.

Edit: I probably should have started this out with a disclaimer:

I learned to program in basic and had this same thought fleetingly about 18 years ago. Trust me, it's one of those things you'll look back on in 20 years and go "Oh, yeah, I was pretty wrong about that" (as I am right now)

Bill K
Expecting a programmer to remember what name he used is the single most fundamental concept in all of programming. How come you could remember it was the word "value" at all? Isn't that bad design? The fact that VB lets you get away with remembering only *some* aspects of the name is just plain silly. Why not remember the first three letters? So Value == Val = Valid? After all, having to remember names is just plain silly.
jalf
The programming/naming conventions for a language will tell you which case is expected for any given kind of identifier.
ChrisW
@csmba: Yes, it is slop. Failing to follow conventions when your tools require you to do so is sloppy.
jalf
@jalf: this has nothing to do with the reasoning for having this "convention" in the first place.
csmba
+2  A: 

Couple of reasons.

  • Finding things, with case-insensitive I'd have to have 'case-insensitive' flag about everywhere. With UTF-8 that should be also aware of Klingon smallcase..

  • More importaintly, CamelCasing, CAMelcaSing. It's not pretty, but it's used a lot and is fairly sane. Is nigh impossible with case-insensitivity.

  • Language parity, for example xsd.exe (shipped with VS200x) can generate you classes for xsd that you supply. What would be your "Value" named when you also have "value"? So this takes out yet another possible impedance.

Pasi Savolainen
@csmba: By the same token, allowing the user to *call* Getage() when the function was defined as GetAge also opens up a case for confusion and bugs. It may not be obvious to the reader of the code which function is called. What is a Getage? It no longer looks like two words, which was the original programmer's intention.
jalf
csmba: I probably said it badly, but camelcasing applies also to namespaces and classnames. So namespaces+classnames which just happen to be foo.lower()==bar.lower() will collide. Also things like GetAway()/GetAWay().
Pasi Savolainen
vb.net will dynamically auto correct you to GetAge(). That is the point.it will help you the programmer to not care what that other guy did, and why should you? all you want is the age already. getAge, GetAge or getage are all the same.
csmba
I will be happy and that is my point: I want GetAway() and GetAWay to be the same thing. and namepsaces should be case insensitive as well.just like URL www.cnn.com and WwW.CNn.cOm should go to the SAME place.
csmba
But *why* should those two URL's point to the same place? They don't look the same to me. You keep asking for factual reasons. It seems you're a bit short on those as well. :)I agree that it's nice when the IDE is able to guess and correct your casing (The C# IDE does the same thing as a convenience feature), but if the IDE is going to correct it anyway, why do you need case insensitivity? Why not have a case sensitive language, and an IDE that guesses the correct casing (and corrects "getage" calls to GetAge, if that's what the function was called) and fixes it on the fly?
jalf
URLs: here is a reason: people (my mom) would not notice that she is trying to log into Citibank.com and not citibank.com. And that makes ID theft easier. (here, I give reasons, I am not about a flame war)IDE auto correct: I agree that good IDE makes either case less of a problem. I didn't say it is an absolute nightmare, I can't handle it. I wrote c++ for many year, didn't bother me. but doesn't bother me <> I have a reason to think it is good.
csmba
+5  A: 

Case rules depend on culture. Do you want a programming language where a variable i is sometimes considered to be the same as one called I and sometimes they're different variables? (That's not a made-up example, btw. In Turkish, I is not an upper-case i.

Honestly, it's pretty simple. Do you want the compiler to correct you when you make a typo, or do you want it to guess at what you meant? The latter leads to bugs, as you found out. VB assumes "oh, you probably meant the same thing, that's ok, we won't stop you", and XML took you literally.

Your bug didn't occur because case sensitivity is bad, it occurred because being sloppy is bad. Arbitrarily changing case may, at best, cause no problems, and at worst it will cause errors. Assume the worst, and be consistent with your case. Which, incidentally, is what case sensitive languages force you to do. Whether or not your tools are case sensitive, the programmer should be case sensitive. Being case sensitive saves you a lot of trouble as long as the world features insensitive as well as sensitive tools. If we could remake the world so that everything was case insensitive, a lot of the reasons in favor of sensitivity would go away. but we can't.

A little side note of course: In many languages, it is common to give variables and types the same names, but with different capitalization:

Foo foo; // declare a variable foo of type Foo

Of course you could argue that "you shouldn't do that", but it's convenient, and it immediately tells the reader what type the variable has. It allows us to create a Log class, and a log object. And since the purpose of this object is to log, the name is kinda obvious.

And a final point to consider:

Case matters in real languages. A word that begins with upper-case is different from the same one but with leading lower-case. The word "worD" is not correct english. Information is encoded in the case, which makes text easier to read. It tells us when we encounter a name, for example, or when a sentence begins, which is handy. Allowing people to ignore case rules makes text harder to read. And since code should generally be written as readable as possible, why shouldn't we do the same in programming? Allow the case to encode important information. In many languages, Foo is a type, and foo is a variable. That's important information. I want to know this when I program. If I see a function called "Getage", I wonder if that's some English word I've never heard before. But when I see "GetAge", I immediately know that it should be read as the word "Get" followed by the word "Age".

By the way, here's a nice example of the fun surprises you can run into in case sensitive languages.

jalf
actually, case sensitive is the case in which the compiler doesn't correct your typo!you can by mistake have in the same class* getAge()* GetAge()adn then the poor user of the class has no clue which one to use. or he may think he calls GetAge and in reality type getAge and get an unexpected result. It never happens in vb.net because it will not let me create such 2 funtions.
csmba
But assuming a *sane* programmer, two functions called getage (with different capitalization) would not exist in the first place. And then the compiler would tell you if you accidentally used the wrong capitalization. The nice thing here is that it would tell you *immediately*, rather than let the issue propagate until it reaches some other tool which *is* case sensitive, such as XML, at which point it can no longer be caught at compile-time, and becomes rather a bug, rather than a simple compile error.
jalf
Edited my post with a few more points to consider. :)
jalf
@jalf: regarding the "case matters in real life.." section.I agree. I don't think that this is again a point PRO the language being case sensitive. You as the programmer are free to use correct English rules when writing your variables and code. In vb.net, if you made a funtion called GetName() then vb.net will enforce that ALL places in the code that use your function are GetName. Pretty no? and in the c# case, you are just as capalbe of writing a funtion gEtnAme() and all users will be using that $%*. so really, it is not a proof that case sensitive lang' is better.
csmba
I didn't say the *english* case rules should be followed when programming (they aren't. We don't even have the concept of sentences, so how can we determine when one starts?). I said that case sensitivity is useful in real languages. And the point I'm making is that if the compiler does not *enforce* correct casing, then we can no longer rely on the information conveyed by casing. If the programmer is "free to follow case rules", you're really saying that he is also free to break them. I have no clue what you mean by the second half of your comment.
jalf
But it doesn't surprise me that you don't consider this proof, for two reasons. First, no "proof" exists. It is simply a point in favor of case sensitivity. It doesn't mean that one is better than the other, it simply means that case sensitivity has at least one advantage. And second, for you to accept this point, you'd have to actually be open about the issue. And you've shown pretty clearly already that you aren't. You've made up your mind.
jalf
A: 

Case is good in programming languages, but rather than use it in symbol names we should use it as it was originally intended- to delimit the beginning of a sentence or command or a proper name. For example:

Var test = 0;
Console.writeline(test);
Test = test + 1;
Console.writeline(test);

So beautiful,... :P

Frank Schwieterman