If you have a problem with case sensitivity, don’t use caps ! If you want to highlight a term, Use an underscore, a dash etc between “words”, instaed of caps. Maybe you could use caps for CHARS, and not for integers ? Why not attack Linux for being case sensitive while yer at it ?
I’ve found the following coding standard quite useful, no matter which language you use:
-
I never use names that differ only by case, so I wouldn’t use an identifier “someObject” and also “SomeObject” or “someobject”, I always let the identifier differ by more that just upper/lower case (in every language).
Reason: It’s just so much easier to have indentifiers that not only differ by case. -
I alwas use the same way of writing an identifier, so even if “someObject” and “SomeObject” are the same in the particular language, I allways call it “someObject”, not “SomeObject”.
Reason: Because when writing code in different languages, you don’t get into trouble becase one language is case sensitive, the other is not. -
I use long names that can carry a meaning, I try to avoid using names that are shorter that tree or four letters.
Reason: Identifiers like “i”, “c”, “f” don’t carry any semantic as to what is stored inside (if the identifier is a variable). It helps understanding the code if the identifiers are a bit more verbose. -
If the compiler/interpreter has got a switch to be more strinct, I use it, because it helps much when finding bugs (or avoiding them alltogether), because if you have to declare variables before use, you get told if you misspell one of them.
For example, I use the following if possible:
C/C++: "-pedantic -Wall -ansi"
VB6 (or earlier): option explicit
VB.NET: option explicit
VB.NET (continued): option strict
Reason: It may seem nonsensical at first sight, but it really helps writing clean, understandable and nearly bugfree code, just try it, you’ll see eventually.
All in all, all of that seems to make sense in any language I ever encountered.
Oh, and I like CamelCasing a lot, but of course your mileage may vary.
The basic premis is a bit lame. KEANU REEVES is or isn’t the same as Keanu Reeves. Why should it be so? In the right context, your vastly more powerful brain looks at the sentence and decides maybe it’s not really an error that counts, and so ignores it. It doesn’t mean it’s correct, and wRitiNG tHIngS lIKe tHIs doesn’t make them right either. Coders aren’t the best linguists so maybe the distinction is lost on the crowd.
I won’t comment on script languages that allow you to use a variable without at least saying
var x;
being explicit allows the computer to help you and anyone reading the code.
However, for “SignOn” != “signon” … blame the coder (unless the tools are deficient).
Newer languages have case insensitive string comparisons, and if you just say string.compare(abc, xyz) and don’t care what kind of compare it uses, and it doens’t work when your user is in Malta, and you didn’t write any unit tests then maybe it’s a shame on you. (hey nobody’s perfect)
Like rolfehub (and others) say, sticking to convention is better and will save your butt, regardless if your compiler thinks of foo and FoO as the same thing. Code is meant to be read by humans.
Linux SHOULD be blamed for being case-sensitive.
Differentiating between variables using case alone is a retarded idea. All the people who advocate disciplined coding ought be shouting loudest that this is a RETARDED IDEA.
Using all lower-case or all upper-case is also a bad idea. Using varied case adds meaning and emphasis to identifiers, whether in C# or in filenames.
What ends up happening is that I use upper-case identifiers for clarity, and then give myself carpel-tunnel enforcing that choice everytime i use the identifier (programming or typing in the terminal).
The best solution is what’s used in VB.net in VS. You declare an identifier the way you’d like it to look, and then the IDE automatically fixes the capitalization after you do the typing all lowercase.
I’m thinking there’s gotta be a plugin that’ll do the same for C#… If anyone knows one, let me know!
As far as I can tell, when I’m developing on Linux, case sensitivity is rarely an issue it all. It improves readability, but doesn’t hurt writability, thanks to near-universal autocomplete, both in text editors and shells.
I agree that differentiating variables by case is a stupid, stupid idea and that case-sensitivity has its roots in keeping compilers simple (and performing well) back in the olden days, but I think case insensitivity is the wrong answer. Sure, Visual Studio will correct inconsistent casing, but do we really want to put this burden on the IDE?
The compiler should deal with this for us. I vote for a case-sensitive language that considers it a compilation error to declare two variables which differ only by casing. At the very least, a warning. This would be pretty much the same thing as having a case-insensitive language where it’s a compilation error to use a casing not consistent with the original one. I suppose some may argue that this will affect productivity in scripting languages, but we can also work the VS auto-case-correcting behavior into the picture.
I think this is a much better solution to this problem than case insensitivity.
Case sensitivity is just something that I learned to live with thirty odd years ago, and I don’t really think about it.
My personal bugbear is meaningful variable names. Criticizing other people’s code is easy. You need to have been coding for a few years, leave one of your own programs and then come back to it to realize how frustrating variable names like “num”, “total” and “max” are.
What has that to do with case sensitivity? Well, whether or no the language is case sensitive, I am still going to use camelCaps and have variable names like “numberOfWidgets”, “maxAllowableBadWidgets” and the like (I don’t like underscores, like “number_of_widgets”).
So, my variable names are either cut and pasted, or autocompleted by my IDE as I type them. I don’t make case-sensitivity errors because of this.
And for those complaining about interpreted languages like PHP, Zend offers an “analyse code” option on the right-click pop-up menu; I can’t speak for other IDEs, though.
Yes, I guess that case sensitivity is a religious thing, but it goes right past me because of the way that I code.
I have to agree with an earlier poster that a case-sensitive language should NEVER allow two identifiers in the same scope that differ only in capitalization. I wish python had that rule, it would solve a lot of problems.
I do see one drawback to case-insensitive languages, though. They allow a programmer to do stuff like this:
for (fred = 1; FRed 100; FRED++) {
wiLMa = frED * 30 + barNEy;
}
which should result in said programmer being immediately shot.
Lloyd, I’ll be sure to add that to my list of approximately 1.2 billion reasons programmers should be immediately shot. 
I’ve been programming for 16 years in C and C++. More recently I have been using Java and C#.
The case sensitivity of these languages have never bothered me. I don’t see why so many are making such a big deal about it.
The way I see it if you spent as much time actually coding instead of writing long posts complaining about this you would have achieved a whole lot more.
I think case sensitivity makes sense because it makes things read easily, and not look like balls - which, in general, aren’t we supposed to be writing code that is easier to understand than it is to write?
Case sensitivity is a useful feature because it forces you to call an object the same name, not so you can have ten objects in the same scope named htmlTag, HTMLTAG, HtMlTag, and whatever other leet garbage you can think of. It’s so someone can glance at your code and have a nice visual reference to HtmlTag everywhere it is referenced, as exactly the same object.
As for your English example, yes, you can capitalize or not random words in a sentence… but it is poor grammar, makes it harder to read, and looks less professional.
I mean, my name is Mike - the naming convention on proper nouns in English is to capitalize all proper nouns. If you write mike or mIke or MIKE I can figure out about whom you are talking… but you’ll look like a twelve year old on IRC.
Case-insensitive languages, by not forcing you into “correct” grammar, lead to sloppy code that is harder to read because there is no consistency. At the very least, they should give a warning or something when you compile so that cleaning it up is easy.
Case insensitivity is downright dangerous in scripting languages where you don’t have to declare or assign values to names before you use them. The language I use will return nil for any unassigned variable name. Also, nil is equivalent to false in “if” statements. This causes some problems. e.g.,
DoIt = foo(blah)
if Doit then
bar()
end
Doit will be nil and bar will not be called. Worse, there won’t be a warning or an error. How to fix this? Make the compiler/interpreter warn if two variables that differ only by case ever exist in the same scope.
Your claim that this is a ‘religious’ issue is just a total cop-out so you don’t ever have to listen to anyone else’s counterpoint.
You don’t really care about the reasons why we have ALWAYS used case sensitivity, you just want to be lazy in your coding, and think that EVERYTHING else should change to suit yourself.
You also blithely assume that english is the only language that matters here because it is what YOU write YOUR programs in. Does case insensitivity make sense at all for other languages?
The argument that keywords are in english while identifers and such will be in a different language is baseless, because keywords are almost ALWAYS CASE INSENSITIVE ANYWAY.
Should we change everything thats already in existence now because you want to be lazier and you keep typing your identifiers with the wrong case?
Your main claim for what makes “case sensitivity bad” is totally weak. You spend a lot of time typing inconsistently, and it is somehow the languages fault?
I have never spent an entire afternoon bashing my head against the wall sorting out a typo. case based or misplaced letters. I am far more liekly to misplace letters than screw up casing.
If you spent more than 15 minutes trying to sort out a typo bug, The issue here is your debugging ability, not your typing. Learn how to better spot problems in your code.
HtmlTag and HTMLTag look completely different, yes if you said them out-loud like spoken english, they would seem the same
But who SPEAKS OUT PROGRAMMING CODE LIKE SPOKEN ENGLISH?
I sure don’t, I read my code, and HtmlTag and HTMLTag look completely different to the eye, what they sound like to the ear is completely useless in the case of written words.
Case-insensitive languages do NOT “lead to sloppy code”. The example given above is defective. In a case-insensitive language, “DoIt” and “Doit” are the same, so the program runs correctly. It’s only in a case-sensitive language that the given example fails (and takes extra debugging time). Smart editors in case-insensitive languages automatically convert all occurrences of an object name to be the same case throughout so there is no confusion or loss of readability.
It’s not just a scripting language vs compiled language issue and Intellisense isn’t available in all languages, editors, IDEs, etc, so it’s not a solution. Even if Intellisense were universally available in program editors, it’s not a replacement for case-insensitivity. Intellisense is a useful enhancement that does make the programmers job easier and less case-sensitive.
Not only should programming languages be case-insensitive, but so should the programs written in them. Since it’s obvious from this discussion that you can’t even get a fairly small group of programmers to agree about case in a programming language, imagine what it’s like for 1 billion users using 50,000 different programs written in 20 programming languages by 200,000 programmers favoring their own version of case-sensitivity. It’s insane. One of the problems of having case sensitive development tools is that it encourages programmers to write case-sensitive applications because that’s what they’re used to. They don’t think about the impact that has on user productivity and training time.
At the risk of offending someone, I offer one of my signature/tag lines: “Case sensitive applications are written by programmers who are too arrogant, too lazy, or too stupid to understand that without users they wouldn’t have a job.”
That’s not to say that case-sensitivity has no place, case-sensitivity does have it’s place, but it should NEVER be the default behaviour. The default should always be case-insensitive and case-preserving with the ability to force case-sensitivity and/or case conversion when it’s appropriate.
Identifiers differentiated only by case are a bad idea. True, there are some in human written languages, but there is no equivalent in spoken languages (at least not the ones with which I’m familiar), so case isn’t the only distinguishing factor, context is more important. Human languages are very tolerant of improper case, so contending that human languages are case-sensitive is a straw argument. “rome wan’t built in a Day” is improper, but perfectly understandable.
US vs. us is an improper comparison, U.S. is the proper abreviation for the United States. He or Him vs. he or him does have a different connotation, but it can generally be inferred from the context, thus the case becomes inconsequential. I could give many more examples, and I’m sure someone will point out an example or two where case is important. However, that simply supports my assertion that case-insensitivity should be the default and case-sensitivity should be used only when required.
The real point of this whole discussion is that we have to start making computers adapt to humans rather than making the humans adapt to computers. Case-insensitivity is one adaption that is fairly trivial to implement and it’s time that it becomes the standard rather than the exception.
Well, funny I’ve never come across a bug related to case sensitivity !
I even find it easier to read initNightRunRun1 than initnightrunrun1, don’t you ?
I’d even be happy to have the langage force me use initNightRunRun1 everywhere after I’ve defined it !
Force me to write readable code ! I like it.
I rather prefer case-sensitive languages (like C#). The casing of a variable denotes the access of the variable-private or public. That way, I can declare a private field, htmlTag, and give it access with a corresponding public property, HtmlTag. At a glance, anyone reading my code can instantly tell what access level anything is. With a case -insensitive language, you can’t do this; you’d have to name the private field something else.
As far as case-sensitive languages generating errors, a good IDE will take care of that with autocomplete. Using C#, Visual Studio suggests the correct variable when I start typing it, no matter the casing I use: upper, lower, mixed, or the correct casing.
While case-sensitive languages ALLOW you to declare HtmlTag, htmlTag, hTmLtAg, HtMlTaG, HTmlTAg, htMLtaG, HTMLtag, htmlTAG, etc. all in the same class, procedure, or whatever, that is really bad style, and should also be added to Jeff’s list of approximately 1.2 billion reasons programmers should be immediately shot. That’s why naming conventions should be followed. Heck, naming conventions make case-insensitive languages more readable.
Anyway, like Jeff said, this is a religious issue. And I’m not a missionary looking to convert anyone. I’m just saying that case sensitive is better.
A language can still force you to write (more) readable code while remaining case-insensitive. Many development environments do in fact convert every instance of a variable name to appear in the same case (either the was it was defined or the way it was last entered). My preference is that my editor/IDE convert a variable name to the same case I used when I defined it, and that it use some form of auto-complete to simplify my coding, however, none of that requires case-sensitivity, only case-preservation.
In fact, an editor that does that conversion for IS in fact case-insensitive, so anyone arguing that such editors are a reason to continue case-sensitivity are completely missing the point. The very tool they’re using to explain why case-sensitity isn’t a problem operates in a case-insensitive manner to ease the difficulty of dealing with case-sensitive languages. That simply just supports my assertion that case-sensitivity is a problem and that case-insensitvity should be the default behavior.
I’ll assert it again, case-insensitive and case-preserving should be the default and case-sensitity and/or case converting (all upper, all lower, or “proper” case) should be options that are used only when appropriate and/or required.
P.S. If you wish to contact me about this, you can do so using my first name and last initial at otcnetworks.com
It’s funny that lots of people talk about how case insensitivity mean that lazy programmers can make the code more unreadable.
I was under the assumption that laziness was a virtue for programmers.
My own brand of laziness with case insensitivity is to use case to denote the scope of variables, and give them all exactly the same name. You can do this with prefixes too. I just find it nice and easy to do with different cases.
… boy did you ever draw up the wrong analogy.
if it is such a problem for you, then just use lower case, or teach yourself to be consistent, a good quality in any developer…
years of using python and case sensitivity is never a problem for me, were you schooled in VB?
programming is about efficiency right? how about using case for scoping? for class names? for the globals you probably use if your from a VB background,
I am strongly in favor of case insensitivity. I grew up on Fortran and Pascal in the 1970s and 80s. (Both case insensitive languages.) Back then I borrowed the style of “CamelCasing” from various systems (such as CMU’s Scribe system.) I found mixed case improved my speed in both reading and writing code. Even VAX assembly language was not case sensitive.
Now I don’t know if its a form of dyslexia or not, but I have found working with all lower case languages tend to slow my visual processing of computer code. (Not to mention C and its heavy use of punctuation like slashes and back-slashes.) When I mix my case I work faster, easier, and more accurately.
Remember, C was not intended to be a high-level programming language. It was meant to be an alternative to assembly language for writing operating system components. The original C case sensitivity was meant to allow for a distinction between a procedure and a related compile time “macro” for the procedure. This distinction in no longer needed in C as a high level language.
But, we are now stuck with C and its derivative languages and the poor design choices made decades ago.