Case Sensitive vs. Case Insensitive Languages

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.

Comments

• Anonymous
  January 06, 2009
  The comment has been removed

• Anonymous
  January 06, 2009
  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.

• Anonymous
  January 06, 2009
  The comment has been removed

• Anonymous
  January 06, 2009
  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.

• Anonymous
  January 06, 2009
  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.

• Anonymous
  January 06, 2009
  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; }    } }

• Anonymous
  January 06, 2009
  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.

• Anonymous
  January 06, 2009
  @Mike, I think it would be interesting to have an optional warning to point out inconsistent case usage in a case insensitive language.  

• Anonymous
  January 12, 2009
  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.

• Anonymous
  January 21, 2009
  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.