What is needed is case CONSISTENCY.
Give me a call about your C/PHP/Python program and I tell you by voice why case-sensitivity is a BAD-THING. I don’t speak in case!
"You need to change your code to CasE, upper-C, lower-a,
lower-s, upper-E".
Case conventions are useful but not for distinguishing namespaces. Namespace checks should be done in a case-insensitive way so I can’t have camelCase, CAMELCASE, camelcase, Camelcase all having different semantic uses.
This is why Visual Basic .NET doesn’t include such little interferences.
The only good thing, I guess, is that the Visual C# compiler is background, so it can catch the erroneous code before you actually debug it.
I find case sensitivity useful for distinguishing between classes and generic members of them; if I only need one object to be derived from a class, then it makes sense to name it similarly. Other than that, I don’t think it should be ingrained into the language’s keywords. What is the difference between “this” and “This”, anyway?
@matt on December 6, 2005 1:23 PM : […] «You’ve got the most important case against case insensitivity there is… consistency. What more do you need?»
What about:
I don’t think that Jeff is looking for real empirical studies.
Can anyone even come up with an anecdote where case-sensitivity was helpful while programming? Come on, even a friend-of-a-friend.
I don’t remember having any problem with case sensitivity. The only spelling-related issues I can think of that caused me debugging problems were in languages like Bash and PHP and they were, most of the time, typos, not bad use of upper/lowercase.
I see your point about case-insensitiveness being more human-friendly but I think that these problems are caused either by not using the right tools or not having a clear style policy.
Also, call me a fetishits, but my eyes bleed when I work with code with inconsistent style conventions. I can’t stand code which uses a different convention for each line and, of course, things like ‘KEanu_reVeS’ and then ‘keaNureves’ will make my head implode.
I’m gonna take the other side of this religious debate.
I’m against anything that lets or encourages coders to be sloppy. Thus letting developers get away with coding a variable or method with 3 or 4 different case spellings is IMHO a very bad thing.
I would extend this languages that allow method calls with “optional” brackets,… JavaScript’s semi-colon “;” line endings are optional (except when they bork your code),… and languages that can’t decide how they want to format their API (I’m looking in your direction PHP! (is it camelCase or underscore_delimited or what))
With a special honorable mention to languages that promote:
“On Error Resume Next” because blindly ignoring errors seems to indicate either the API is not stable or in need of a try/catch/finally concept.
ExpertsExchange != ExpertSexChange
/thread
I JUST TYPE EVERYTHING IN ALL CAPS, ALL OF THE TIME.
WORKS FOR ME.
We wouldn’t have this problem if computers now are able to catch these errors at parse-time, to correct the mistakes we had 40 yrs ago.
So, if you had 3 staff members all called Robert, you’d give them email names of robert, Robert, and ROBERT would you?
You’d just trust that you weren;t sending the business plan to the Robert who was a director, not ROBERT the staff member who was disgruntled and wanting to leave?
Isn’t is far better to call them RobertA, RobertB, and RobertC if they had e.g. surnames of Arkwright, Briggs, and Carter?
Anyone who creates variables called cabbage and CABBAGE in the same block deserves to be sent on a training course at best, demoted to tea boy at worst. You’re just asking for trouble, the rich features in the english language (which is of course the same as the English language) should encourage you to use more descriptive varied names, such as
BoiledCabbage, CabbageShoots, HarvestedCabbage
Use your imagination a bit more!
I like case sensative. We use lowercase to denote private variables and
uppercase to denote public ones. Makes it a lot easier to keep track of
things without having to modify the names themselves.
As a general convention it’s not a bad idea as long as the public variable is name slightly differently to the correpsonding private one
However, code like the below is a horrible habit that deserves to go down the waste bin of history
//this sucks
private string name; // the name field
public string Name // the Name property
get{
return name;
}
It can lead to the wrong variable being referenced within a class which will be totally undetectable by the compiler, and easy for a human to miss because the words are so similar.
It is also confusing to anyone learning the language for the first time to see such examples. Things which are different should jump out at the user as being different.
I remember the confusion I felt learning java when the examples were just “hello world” ones with the program name, method and filename all being called “HelloWorld” endless sub main, files called main etc - conceptually different things all called the same name. Oddly enough, when I wrote a more complex program that did different tasks it suddenly became a lot easier to understand.
What’s wrong with a naming convention which relates concepts clearly but does not duplicate them? See below.
//this is a lot clearer
private string nameM; // the name field, M for member
public string Name // the Name property
get{
return nameM;
}
Aside from aesthetics (some might prefer NameM, name_m or even name_) it’s pretty obvious which public properties go with which variables, and it’s glaringly obvious which of the two you’re using!
I like suffixes rather than prefixes because these keep the two together in the intellisense (I understand the dislike of Hungarian mName variables for that reason)
The argument the other way is rather like arguing that it’s better climbing without a safety rope as you should always be able to put your foot in the right place every time! People make mistakes, we set up systems to prevent them and highlight them.
Something that would maybe work but that would be utterly horrible language-theory wise (almost PHP level horrible):
Case insensitivity unless you define two identifiers with different casing explicitly.
int asdf = 5;
int fdsa = ASDF; //is 5
Person therapist = getTherapist();
Person theRapist = getTheRapist(); //different from therapistA couple of people have asked for when case-sensitivity is useful.
This common example springs to mind:
var spoon = new Spoon();I like you very much guys but case sensitivity has some advantages.
I code a lot in Java and we have good IDEs (Intellij) that will visually display the naming problems.
For the rest, most of the problems are detected at compile time.
If a developer makes usage of the same variable in same name space, I don’t want the developer to be able to use case insensitve naming. We focus a lot on conventions and it is true that in Java you will never ever instantiate an object making ref to a class that does not beg with a character in upper.
If you read the chapter 2, ‘Meaningful Names’ from ‘Clean Code’ from Bob Martin, camel case is used everywhere. It is a good reference to discuss this topic.
Cheers