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.
One thing no one should doubt is that case-insensitive is better for beginners. It lowers the amount of errors beginners make, and thus lowers the bar of entry.
Look at all the development environments designed with beginners and non-programmers in mind, and they are case-insensitive: pascal, HTML, SQL, logo and its variants, BASIC and its variants including visual basic, etc. Even the creator of python wanted to change python to be case-insensitive, explicitly because it was a source of errors with beginners, but was rebuffed by some existing python users.
That said, people aren’t thinking outside of the box here. It is possible to support both. You can have a compiler that is case-sensitive, but uses case-insensitive matching on failure. It’s very simple to implement, I’ve done it for boo, which is nearly identical to python syntax-wise. It can also check for names that vary by naming style (SomeName vs. some_name). That allows people to get away with a lack of creativity in variable naming:
dog = Dog(“Rex”)
yet still not have to memorize the exact naming style of some method.
Even that isn’t thinking outside of the box enough. Again, look at development environments designed for children and non-programmers to see other ideas, such as the graphical building blocks used in lego mindstorms, scratch (http://scratch.mit.edu/), Labview, Yahoo Pipes, and other recent web 2.0 ides.
Doug, I agree… a compiler should warn the user that there are two similar variables being used with different case. Languages them selves should not permit case sensitivity, for the same reason Ada does not permit it. Unfortunately even Wirth has designed Modula/Oberon to be case sensitive… worse yet one must type BEGIN and END reserved words in CAPS LOCK.
Correction: I agree with doug about people not thinking outside of the box, I still think case insensitivity is nice, and NewDog or DogCast is better than the more confusing dog and Dog.
The one, and only, situation in which any string comparison should be case-sensitive is passwords. The cost of the decision, for example, to make the *nix file system case-sensitive is almost certainly now in the 10s of millions of dollars and increasing every single day. Unacceptably foolish.
First and foremost, it makes Foo and fOO used for the same variable a debugging issue instead of maintenance by a future coder issue.
Second, in some languages, for example Java, Foo and foo are assumed to mean different things. Foo is normally class name, while foo is variable/method name. In some languages, for example Haskell, that is even compiler enforced. In those languages, letting Foo and foo mean different things is a good thing. For example “public void setFoo(Foo foo)” is a frequent pattern in Java code.
Also, I’d like to ask if anyone here would submit code with two different spellings of a variable name and not be embarrassed about it later. (I’m actually curious.)
Jeff, if you had an IDE that told you you spelled ‘console’ incorrectly, would that make you happy?
And finally, some anecdotal evidence of case-sensitivity being helpful:
A friend of a guy I think I know was maintaining some code. There was a function called diveRunDo. However, since he was using a case-insensitive language, when a coworker called that function but used diverUndo, the compiler didn’t complain. So my friend spent hours trying to figure out why the diver’s last action wasn’t being undone.
So that’s not true, but I can imagine many such problems.
Case sensitivity lets the worst instincts of developers run wild.
I would say that lax rules let the worst instincts run wild. Really, instead of case insensitivity, a better solution would be something like what Maciek suggested: The compiler complains when you use variables that only differ by case.
I see enough spelling mistakes in comments (even though VS highlights them), I don’t need to see them in variables. ANd don’T improper CAPITALs bother yoU?
Typos aside, I think this problem pretty much goes away when you come up with a variable naming convention and stick with it.
I’ve been bitten by similar identifier problems in scripting languages, but to my knowledge, it was never a case thing. It was always something like “varlist” versus “var-list”, or changing the name of a variable and missing one accidentally (oops, didn’t do a global search and replace.) Caps have never bugged me.
Should be obvious:
One place the case-sensitivity problem can be tackled is in the IDE or editor.
I know this sounds almost off-topic, but how feasible does changing the syntax conventions of languages look when millions of lines of code are running in production use across the world and your new version comes as an upgrade?
IMO, For all practical purposes, we can do almost nothing about these time-sinks. Requiring people to readjust their habits and thinking, which they’ve comfortably lived with for years? It’s easier to become Bill Gates.
…
Or is it The System’s way of ensuring that we don’t reach the best possible language syntax ever? That we constantly keep making mistakes and then repairing them when we find them?
All humans, after all…
(PS: Sorry if I didn’t read a similar comment above - there’s probably a hundred of them…)
i’ll actually often use the same name with different capitalisation for multiple things. Most notably classes and variables which hold instantiations of those classes.
For example, in Javascript:
function Client() { }
(yes, this is how you make a class in JS)
var client = new Client();
because I always use UpperCamelCase for classes and lowerCamelCase for variables, I don’t have to resort to vUsing adjHungarian nNotation, or my other favourite method when not using a case-sensitive language:
var myClient = new Client(); // or,
var theClient = new Client();
Writing KEANU REEVES in english rather than Keanu Reeves is just as incorrect a use of the language as cap mistakes are in C. The difference is that the compiler for the english language (or any other human language), the human mind, is insanely much more powerful than any compiler for a computer language, and thus can figure such ambiguities out, just as it can decode spelling mistakes, incorrect grammar, understand accents when compiling spoken languages etc. This doesn’t mean that it’s right to type kEanu ReeVes, just that the compiler catches the mistake and corrects it automatically.
‘I spend an hour today debugging a possible problem only to notice that “SignOn” != “Signon”.’
Is that any decent tool would alert the coder to his mistake unless he had used both SignOn and Signon as variable names, in which case, thats the programmer’s own fault for using variables with similar names. Certainly should not have taken an hour to notice…
As much as case sensitivity causes a problem it can at least be worked around with a good compiler/interpreter. I totally agree that any new language should not be case sensitive though… I struggle to think of any reasons why that is a good feature for the user, it just makes things easier on the developer /sometimes/… after all, almost every major language comes with some kind of case-insensitive comparison in its libraries (even the notoriously unfriendly C++ has “stricmp” and friends).
In my opinion case sensitive source code is (much) better because it is easier to read.
Having the same identifier always written with the same ‘casing shape’ helps me to spot its repetitions in a page of code quickly: actually spotting the shape of the word before I even read it.
I find it takes longer to read code if the casing always changes.
In the second example it’s more obvious to me that just one variable is involved in the computation.
Case sensitivity is useful in the same way as indenting, aligning and using blank lines might be: it helps readability (not as much as correct indentation of course).
Of course writing in a case sensitive language takes (a little bit) more time but since we read source code more often than we write it I believe it is a performance improvement after all and I like it enforced by the compiler.
So you wanted a real world example in regard with case sensitivity being helpful rather than just spoiling all the fun?
Well, here’s one. Imagine that there’s some Matrix class:
The company I work for has a procedure in place where any code changed by one developer must be checked by another. This is normally done by comparing the code before changes to the code after changes using a diff tool. VB, with it’s code insensitivity, drives me insane everytime I have to do one of these comparisons. There’s always a bunch of variables that have changed case (usually because the developer accidently changed the case of one instance and the IDE decided to help out and changed the rest).
Now, I could change the diff tool to ignore case, but then strings presented to the user may have changed, so users end up with badly Capitalised sentences (which drives my manager insane). So, VB’s case insensitivity is a right PITA, which C# gives me no problems at all.
I think his whole whining about case sensitivity is pretty silly.
As for scripting, people are not more prone to “mis-case” a name string than mis-spell it in other fashions, especially if he or she adhers to sound naming conventions, like “all english words in a name start with an uppercase letter”.
So you could argue that not only case sensitivity should go, but also any sort of precise spelling. Yeah, let the compiler guess what is closes to the declared names, right? Would be so cool.
No it woulnd’t, it would be ambiguous shite, just like case insensitivity.
I think we should not revert our languages to pre-stoneage behaviour, especially not for such silly reasons.
How about this:
demand programmers/scripters to adhere to sound naming conventions (consistent inside company)
use tools to check every script’s strings against the declarations for ANY sort of misspelling. If there’s a string found that’s not declared, this is a syntax error !
The fact that scripting works so much with strings to call things makes these into somewhat of a language feature that should be checked by the language for correctness…
If no such language or external tools are available, make them yourself, damn it, it’s a piece of cake.
I prefer my compiler to not attempt to mangle isLand() to Island() or vice versa, depending on which declaration came first, thank you very much. And using a camel naming convention without underscores makes me more efficient, because it helps wrong things to look wrong, just like Apps Hungarian notation does, so I will spot them early and fix them early. And even if I do fail to spot the problems, the compiler will barf on it instead of silently incorporating the problem into the runtime, making for an earlier failure (which is also a Good Thing). Sure, I could circumvent this by not using case, but rather underscores and whatnot, but case is in my opinion better precisely because it’s natural: I can identify/separate words based on capitalization faster than I can spot underscoring differences, and I still see them as a single block of text and not several pieces connected by something else.
In any case, whatever your preferences may be: you’re just a short lowercasing/case-translating script away from following your own conventions regardless of the compiler’s/interpreter’s needs, so there’s no need to be aggressive about it.
