.
Just had a random thought while I was looking at some code today. It’s yet another argument in the case sensitive vs. case insensitive language battle.
Do you really want this to be able to compile?
class C1 {
int M1;
int m1;
}
Yes it’s an abuse and should absolutely be caught in a code review. But at the same time, experience has taught me that if an evil thing can be done with a language, someone will do it.
And yes, sadly I’ve seen code like this before.
Published Tuesday, January 06, 2009 8:00 AM
by
Jared Parsons
The real issue is: "are humans case sensitive?"
If they are then case sensitive languages are OK but otherwise not - because high level languages are for humans not computers :-)
Duncan
Well, I wouldn't mind if a compiler would complain about your example but then I also expect a compiler of a case insensitive language to complain about this:
Dim a As Integer
Dim b As Integer
If (a = B) Then ...
Yes, I know the VB editor will automatically change the "B" to a "b" but the point is that each aproach has its drawbacks.
Mike
Do you really want this to compile?
void foo (int bar)
{
++ Bar;
baR*= 2;
Print (bAr);
}
Fabien
There's no existing language that prevents the user from doing any evil things..
Anyway, in terms of evilness, that code sample ranks pretty low. It doesn't compare to the tremendous awfulness of living in a case-insensitive world.
andy
The case distinction can be useful, for example it's common to use all-uppercase for constants, or have class names begin with uppercase and other names begin with lowercase.
Being case-insensitive could also get confusing for languages that have more than two forms of some letters. I don't have an example, but it seems like there could be a language where the canonical form of an identifier would be effectively spelled wrong.
You also expose more APIs (reflection, code generation, etc.) to i18n issues, to handle case correctly. This is annoying and has performance implications.
In short, leave my identifiers alone. OTHERWISE IT LOOKS LIKE COMMON LISP.
Jeff B
I think it's usefull in languages with different access modifiers (public/private)
public class MyClass
private int myInt;
public int MyInt
{
get { return myInt; }
set { myInt = value; }
}
Alexander
Probably a hybrid would be best. Redeclaring the variable in a different case should be a compiler warning, and the first declaration should be invalidated. Using a case different than the last valid declaration should be a compiler error. That lets you use whatever capitalization style you like, and enforces it for every use of that identifier, but prevents case-insensitive-identical names.
Karl
@Mike, I think it would be interesting to have an optional warning to point out inconsistent case usage in a case insensitive language.
Jared Parsons
It seems like you are focusing too much on protecting the programmers from themselves. While noble, it shouldn't happen at the cost of useful features.
Most notably what Alexander mentioned, cases where you have two of basically the same thing in different guises. So long as picking the wrong one isn't a huge deal, and both aren't publicly visible, it can be very helpful.
Joshua
I think this is a style preferences and should be enforced by the tools instead of the language.
Tools like Checkstyle for Java (checkstyle.sourceforge.net) could be used to enforce a coding conventions for case.
Having a convention like lower-case member variable names could prevent the m1/M1 problem, but would not prevent you from doing something like mtwo/mTwo.
ben