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 (10)

  1. Duncan says:

    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 :-)

  2. Mike says:

    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.

  3. Fabien says:

    Do you really want this to compile?

    void foo (int bar)

    {

      ++ Bar;

      baR*= 2;

      Print (bAr);

    }

  4. andy says:

    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.

  5. Jeff B says:

    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.

  6. Alexander says:

    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; }

       }

    }

  7. Karl says:

    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.

  8. jaredpar says:

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

  9. Joshua says:

    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.

  10. ben says:

    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.