People who like case insensitive languages are just lazy.
How is cabbage equal to CABBAGE atall? Doesn’t make sense!
As a PL/SQL programmer I can say that
v_person_name = V_PERSON_NAME
but
‘Smith’ ‘smith’.
Variables need to be parsed only at compile time, so no worries for tiny performance penalties there. Person names, OTOH, need to be compared millions of times a day. So you trim every fraction of a second where you can.
Many years on and this argument still hasn’t been settled… I doubt it ever will be but here is my 5c worth (cos our government stopped making 2c a long time ago):
Using case sensitivity to refer to different variables is just plain stupid. I program primarily in C# but the only time I (or anybody I have ever worked with) make use of differing case to name things is in the case of a property and it’s backing store; after all, they are two different ways to expose the same data (external and internal respectively, when used properly). That gives a clear indication that they are related without having to add on wasteful prefixes.
I agree with Wayne Kroots, casing is simply a matter of style, the consistency of which should not depend on the language. Do whatever makes the code more readable, even if that means maintaining proper casing in languages like VB.
As for Scott Hanselman’s case, it is unclear if his problem was casing of the variables themselves or the string values they represented. Any language should be able to perform both case sensitive and insensitive string comparisons, it’s up the programmer to decide when and how to use which.
Finally, to Jeff Atwood, you kept saying you were only able to find documented cases of case sensitivity hindering developer performance. Something all of us as programmers should be aware of (based solely on user feedback if nothing else) is that people are quick to complain when something doesn’t work the way they expected, but much (much, much, much, muuuuuuuuuuuuuuuuuch) slower to praise when it does. With that in mind, don’t expect people to blog about how case sensitivity just saved them hours of debugging (most programmers will either go home early or find something else to code).
Ph03n1X
Glorified Typist
Earth
P.S. Got tired of reading all the comments so I stopped after about 30 and jumped to the bottom, I’m very sorry if I’ve repeated anything said before 
I think having a case-sensitive language ENCOURAGES people to write poor code.
Const SHOESIZE = 9
Class ShoeSize
ShoeSize.shoesize
call function shoeSize(SHOEsize)
{
int ShoeSIZE = 10
return ShoeSize
}
Duh. You couldn’t think of a better variable name than ShoeSize for the different purposes??? There a billion different words you could use… but you choose to just keep using ShoeSize instead?
I can’t believe I just read two years worth of comments saying that case insensitivity leads to hard to read code. Just because a language is not case sensitive, doesn’t mean that it won’t let you use variables with a casing convention that conveys meaning.
Case preservation is what creates readable code, not case sensitivity. I write VB.Net every day and we have strict case conventions. We catch violations through code reviews just like everyone else does. Writing in C# doesn’t automatically cause developers to adhere to sane case conventions.
There is no case, other than using case to distinguish between variables, where an identical casing convention cannot be followed in a case insensitive language. You can write C# in all lowercase if that floats your boat (except for calls to the framework). You’d be just as much of an idiot to do it in C# as VB.
Let me repeat – the only case where case sensitivity has an actual end-effect is the where two variables are distinguished only by case. Since this is a practice not recommended by Microsoft, there is actually no likely case where there will be a functional difference. Also, since VB is case-preserving, there is no case convention that is not allowed or not preserved (other than the affore mentioned not recommended practice).
The only difference is that a case typo is auto-fixed in the VB IDE and caught by the compiler in C#. If you make a legitimate typing mistake in either language, it won’t compile. Learn ctrl-space and you will never make either a casing or a typing mistake. The only reason case insensitivity hasn’t been removed from modern compiled languages is that is pretty much doesn’t matter any more. Since case sensitivity has traditionally been there in C type languages and removing it will cause a lot of code to not be directly reusable, the minimal costs of changing it outweigh the almost unmeasurably small benefits of getting rid of it.
it makes no sense.
but yes, I guess it is a religious issue as the comments I am getting here http://stackoverflow.com/questions/895423/case-sensitive-vs-insensitive-syntax are not to the point, but with lots of emotions.
What is needed is case CONSISTENCY.
Give me a call about your C/PHP/Python program and I tell you by voice why case-sensitivity is a BAD-THING. I don’t speak in case!
"You need to change your code to CasE, upper-C, lower-a,
lower-s, upper-E".
Case conventions are useful but not for distinguishing namespaces. Namespace checks should be done in a case-insensitive way so I can’t have camelCase, CAMELCASE, camelcase, Camelcase all having different semantic uses.
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:
- IntegerDaysOld
- IntegerDaySold
?
LOL
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.
1 Like
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.
1 Like
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 therapist
1 Like
A 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
2 Likes