Framework Design Guidelines: Case Sensitivity

Continuing in the series of discussing topics from the Framework Design Guidelines


Expert from 3.1.4 Case Sensitivity


Languages that can run on the CLR are not required to support case sensitivity,

although some do. Even if your language supports it, other languages

that might access your framework do not. Any APIs that are

externally accessible, therefore, cannot rely on case alone to distinguish

between two names in the same context.

DO NOT assume that all programming languages are case sensitive.

They are not. Names cannot differ by case alone.


PAUL VICK When it came to the question of case sensitivity, there was

no question in the minds of the Visual Basic team that the CLR had to support

case insensitivity as well as case sensitivity. Visual Basic has been case

insensitive for a very long time, and the shock of trying to move VB developers

(including myself) into a case-sensitive world would have made any

of the other challenges we faced pale in comparison. Add to that the fact

that COM is case insensitive, and the matter seemed pretty clear. The CLR

would have to take case insensitivity into account.


JEFFREY RICHTER To be clear, the CLR is actually case sensitive. Some

programming languages, like Visual Basic, are case insensitive. When the

VB compiler is trying to resolve a method call to a type defined in a case sensitive

language, like C#, the compiler (not the CLR) figures out the

actual case of the method’s name and embeds it in metadata. The CLR

knows nothing about this. Now, if you are using reflection to bind to a

method, the reflection APIs do offer the ability to do case-insensitive lookups.

This is the extent to which the CLR supports case.

Comments (14)

  1. Shoddy Coder says:

    I’m enjoying "the series", thank you!

  2. Jeff Atwood says:

    I’ll never understand why, in this day and age of 3+ghz processors, case sensitivity is required at all.

    Sure, K&R did it that way in 1978– but was every decision from 1978 meant to be binding into the next century?

  3. Chris Nahr says:

    Case sensitivity has nothing to do with processor speed. Folding case in the small ASCII character set that’s legal for identifiers is a trivial task on any hardware.

    Case sensitivity is a deliberate feature. It’s useful because you can differentiate the names of public and local/private entities merely by case, sparing both the programmer and the reader of the program from having to learn some special prefix.

    This feature also parallels mathematical usage where you’d write a for a scalar and A for a matrix. Not to mention common day usage where you’d capitalize terms to indicate proper names rather than general nouns. Nobody seems to have a problem with that… it’s not as if casing was hard to distinguish, after all.

  4. Jeff Atwood says:

    > It’s useful because you can differentiate the names of public and local/private entities merely by case, sparing both the programmer and the reader of the program from having to learn some special prefix.

    Wonderful. I can’t wait to support your code, full of "string case" and "string Case".

    Because that’s not confusing at all. No. UNLESS YOU’RE A ROBOT.

  5. Michael says:

    Something like this:

    string case = "foo";

    public string Case


    get { return case; }


    makes a lot more sense to many people than:

    string _Case = "foo";

    public string Case


    get { return _cASE; }


    Case sensitivity is a good thing.

  6. Warwick says:

    > Case sensitivity is a good thing.

    Agreed. The chief advantages of case sensitivity are accuracy and disambiguation. The main costs are difficulty of recall and typing, which are addressable with case insensitivity.

    When IDE features such as intellisense are available, these costs largely disappear, as does the case for case insensitivity.

  7. BradC says:

    Case sensitivity is the primary reason that I may never feel at home in C#.

    And the (imho stupid) practice of deliberatly introducing variables, properties, or functions that differ only in case is only a part of the problem.

    My life-long habit in (vb) programming has always been to type in lowercase, and let the IDE correct case for me–I actually use this as a subtle "check" that my syntax is correct as I’m typing.

    When programming in C#, the interface doesn’t do this for you. If you type "system." it just sits there staring at you. You have to backspace over the whole thing to type the capital S in "System." to get any intellisense. ASTOUNDINGLY annoying.

    I suppose if I had any large C# projects, I might spend enough time in there to get used to this, but at this point, I don’t see any point in worrying about it…

  8. Wei says:

    What about case-insensitivity in the Windows OS itself? e.g you cannot have two files named A.txt and a.txt in the same folder.

    I prefer case-sensitivity, which makes things more rigorous; and i guess the loose way MS deals with this issue (as compared to the strict way Unix does) is why MS developers are often perceived as being inferior, although this bias is prob wrong today.

  9. Chris Nahr says:

    In the case of the file system, I think Windows has it right.

    When you use the wrong case while writing a C# program you get a compiler error, or IntelliSense doesn’t come up… big deal. When you use the wrong case in a case-sensitive file system, you might delete the wrong file!

    Also, files on Windows systems are created by users, i.e. normal people, not just programmers, so it makes sense to reduce the possibility of such errors as much as possible.

  10. Dhominator says:

    BradC… just hit <ctrl><space> before the ‘.’ and the IDE will correct casing for you (anywhere).


  11. Shawn Oster says:

    Ahh, I had gone almost a week without a good Case Sensitivity Holy War. I do love to watch the monkeys fling poo. I feel supporting case insensitive languages is important because it helps give this whole debate even more room to blaze.

  12. Random Reader says:

    > What about case-insensitivity in the Windows OS itself? e.g you cannot have two files named A.txt and a.txt in the same folder.

    Actually you can, just not using the Win32 API. NTFS itself is case sensitive, not merely case-preserving. The POSIX subsystem uses case sensitivity, for example.

    You won’t ever convince the Explorer shell to handle A.txt and a.txt correctly though 🙂

  13. DougK says:

    I’ve liked the progression of technology over the years that has allowed developers like myself to be more productive.

    However, case sensitivity, in my experience, is a step backwards for productivity. Case sensitivity definitely slows me up and makes me less productive than when I’m working with case insensitive languages. If I run into one case sensitivity issue while I’m coding, then I’m less productive than when working with case insensitive languages; I’ve run into more than that. I see 0 benefit to having same named things differentiated by case; it seems at odds with the goal of trying to make code more understandable to more people, thus reducing the productivity of anyone that has to work with or understand the code.

    As a human, I think that a Dog is a dog is a DOG. As a software developer I think that a TDogObject is a tdogobject is a TDOGOBJECT. I find the first one more readable but I don’t want to trick myself into believing that it is different from the second one or the third one.

    Now that I’m working with C# more often, the case sensitivity is one of the things that annoys me. I thought that the world would have realized that case insensitivity is the way to go and any new languages would take that into account. It would be nice (maybe it’s possible and I’m unaware) if I had the option to choose case insensitivity in case sensitive languages like C#. It would make those languages more inviting and more productive for me.

Skip to main content