The Case For Case Insensitivity

blog
121

For speed I usually cut n’ paste identifers in C++/.net/Java so very rarely do I ever have case sensitivity problems - and anytime i do I get compiler errors. Parsed languages will catch most such errors unless they decide to define/allocate a misspelled varaible as a new one and use it wihtout warning, review your choice of coding language if this is problem. Humans are sloppy granted - and should be allowed some slack, but programming should still be a matter of precision so I see no major reason why case-sensitivity should degrade coding efficiency unless one is being ruthlessly sloppy.

You’ll be happier to read neat consistent, properly indented, spaced and commented code (with hungarian notation or similar) rather than a mess of mixed casing and multiple naming paradigms.

Finally if you have time to worry about case-sensitivity vs coding efficiency then obviously more important things like your software design and algorithm efficiency must be impeccable. Otherwise worry about that first!

122

Of course we need case sensitive languages. Those stupid case insensitive languages don’t leave me enough namespace for variable names and are too restrictive!

Case sensitive languages let you powerful things like have the variables myCow, MYCOW, mYcow, and mycow all in the same scope with different types.

Case closed! On to Hungarian notation…

123

“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.”

My IDE (VS.NE) automatically fixes the case in my code to match the declaration at dev time and I get the same benefit.

I guess it is like those woodworkers who insist on chiseling their own mortises, it might not be as clean, but at least it takes twice as long!

124

I like the isLand() - Island() comparison. Also, here’s one adapted from an episode of Squidbillies…

Therapist - theRapist

Hmm. Perhaps case sensitivity is a good thing after all. I wouldn’t want to get those two confused.

125

“Well, funny I’ve never come across a bug related to case sensitivity !
I even find it easier to read initNightRunRun1 than initnightrunrun1, don’t you ?
I’d even be happy to have the language force me use initNightRunRun1 everywhere after I’ve defined it !”

If C# were case insensitive why wouldn’t I still be able to use ‘initNightRunRun1’ ? And in the IDE, if we tried to type initnightrunrun1 after the original ‘initNightRunRun1’ was used then intellisense should correct it. So, I agree that the IDE should help keep the variable names pretty and enforce only one version ( case combination ) of that variable name. And why not add that as an option to Visual Studio ? What could it hurt ?

But why oh why does it allow something like the following ?

foreach (Order order in orders)

When I see this it makes me cringe. Talk about sloppy coding. If you’re insistent on using the name ‘order’ in the first two variables then why not prefix it with something meaningful instead of using case ?

126

I like case sensative. We use lowercase to denote private variables and uppercase to denote public ones. Makes it a lot easier to keep track of things without having to modify the names themselves.

127

I love case sensitivity.

I do.

128

I’m not agree with it that case insensitivity is a much more human being friendly design choice. I think that case insensitivity is NOT much more human friendly design choice. I wrote about this in my friend’s blog on http://detoxmed.com. I think that’s be useful.

129

@Kris: We use lowercase to denote private variables and uppercase to denote public ones.
But you can still do that, even in a case insensitive language. You just can’t use the same word. Which isn’t particularly valuable in the first place.

130

As for Python and case sensivity - that’s why we all have that nice autocompletion feature in our code editors.

I usually only write a word completly once, all the rest instances are autocompleted after first 3-4 letters I write. When I misspelled these first letters something wrong or nothing at all will show instead, so I will notice this.

Autocompletion is IMHO the single most important text editor feature, even more important than syntax higlighting.

PS. when writing graphic/physic code in C++ I often name my variables X,Y,Z when refering to world coordinates, and x,y,z when refering to object coordinates, it also aplies to other short names mostly used in numerical algorithms. I can’t persuade myself to use normal camelCase convention there, it would make my nice equation 4 time as long, and I would have to break it into many lines. It’s like in math - differenting variables by case is sometimes useful, mainly when there is some constant relation between every big and small case variable.

131

Many posters are still confusing case sensitivity with case preservation, they are NOT the same thing. Case preserving means that something kept using the capitalization as it was typed. Case insensitive means that case is not relevant when comparing a string (e.g. a variable name, class name, etc).

In a case preserving system, you can use CamelCasing (or camelCasing), if the system is case insensitive, then Foo=foo, but in a case sensitive system Foo != foo.

People read mixed case text faster and more accurately than all upper or all lower case, there have been numerous studies that demonstrate that (you can google them if you want). This alone is a very strong reason for case preservation. Case preservation also provides clarity, ExpertsExchange clearly has a different connotation to the reader than ExpertSexChange and either is much clearer than expertsexchange. Case preservation is a great thing, I’m very much in favor it of.

Using only case to differentiate variable scoping is absolutely unacceptable. I don’t have as big an objection to using it to distinguish an instance vs. a class, but I do think it’s a poor practice.

As I mentioned in a previous post, case sensitivity is sometimes necessary and appropriate, however, I’m opposed to case sensitivity in most instances.

In fact, for clarity, I’m going to stop using the terms case sensitive and case insensitive and start using case dependent and case independent.

Variable, class, function, procedure names should not be case dependent. Program names, command line parameters, and program input should not be case dependent, EXCEPT when necessary and appropriate.

In a well designed case preserving, case independent system with an editor that provides auto-completion, you get the best of both. All variable/function/procedure/class name is converted so that all instances have the same case. It is preferable that all instances are converted to use the case used when the object was declared or defined, that way the developer only has to worry about getting the case correct one time, and all other instances will be converted to match that one.

The only thing you can’t do in that environment is use ONLY case to differentiate the scope (or differentiate between an instance and a class). For instance, you can’t use var client = new Client You can still use case to differentiate a class, instance, or scope, but you can’t use ONLY case. For example, you can use var curClient = new Client. You can also use Hungarian notation.

This allows for writing very readable code that is more maintainable by another developer. It also creates code that is portable to another system/language while minimizing the problems of different variable scoping rules, syntax differences, etc.

132

Code is read more than it is written.
And a case sensitive language forces you preserve the case.
A variable named greenHorse is more readable than GREENHORSE,greenhorse or GrEeNhOrSe,…

And while I know you can just use case preservation in a case insensitive language, it is my experience that unless it is enforced(like with a case sensitive language) People just won’t do it.

PS. the argument that an IDE like VisualStudio will autocorrect case preservation in a language like VB.NET is void, since it will also autocomplete case sensitive variables in C#/C++. thereby avoiding the differentCaseDebuggingProblem.

133

IMHO case sensitivity should not matter to the programmer. I believe it is part of good coding style to type identifiers in a consistent manner whether or not the language in question is case-aware.

Would you really feel happy with a code block that refers to both FOOBar and fooBaR?

134

I got into the habit of assuming that the language I’m writing in is case sensitive. I only recently realized that PHP’s functions are not case sensitive! I can’t remember the last time that I actually had an error because of case sensitivity, it has become a way of coding for me.

135

People who like case insensitive languages are just lazy.

How is cabbage equal to CABBAGE atall? Doesn’t make sense!

136

As a PL/SQL programmer I can say that

v_person_name = V_PERSON_NAME

but

‘Smith’ ‘smith’.

Variables need to be parsed only at compile time, so no worries for tiny performance penalties there. Person names, OTOH, need to be compared millions of times a day. So you trim every fraction of a second where you can.

137

Many years on and this argument still hasn’t been settled… I doubt it ever will be but here is my 5c worth (cos our government stopped making 2c a long time ago):

Using case sensitivity to refer to different variables is just plain stupid. I program primarily in C# but the only time I (or anybody I have ever worked with) make use of differing case to name things is in the case of a property and it’s backing store; after all, they are two different ways to expose the same data (external and internal respectively, when used properly). That gives a clear indication that they are related without having to add on wasteful prefixes.

I agree with Wayne Kroots, casing is simply a matter of style, the consistency of which should not depend on the language. Do whatever makes the code more readable, even if that means maintaining proper casing in languages like VB.

As for Scott Hanselman’s case, it is unclear if his problem was casing of the variables themselves or the string values they represented. Any language should be able to perform both case sensitive and insensitive string comparisons, it’s up the programmer to decide when and how to use which.

Finally, to Jeff Atwood, you kept saying you were only able to find documented cases of case sensitivity hindering developer performance. Something all of us as programmers should be aware of (based solely on user feedback if nothing else) is that people are quick to complain when something doesn’t work the way they expected, but much (much, much, much, muuuuuuuuuuuuuuuuuch) slower to praise when it does. With that in mind, don’t expect people to blog about how case sensitivity just saved them hours of debugging (most programmers will either go home early or find something else to code).

Ph03n1X
Glorified Typist
Earth

P.S. Got tired of reading all the comments so I stopped after about 30 and jumped to the bottom, I’m very sorry if I’ve repeated anything said before :wink:

138

I think having a case-sensitive language ENCOURAGES people to write poor code.

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize

call function shoeSize(SHOEsize)
{
int ShoeSIZE = 10
return ShoeSize
}

Duh. You couldn’t think of a better variable name than ShoeSize for the different purposes??? There a billion different words you could use… but you choose to just keep using ShoeSize instead?

139

I can’t believe I just read two years worth of comments saying that case insensitivity leads to hard to read code. Just because a language is not case sensitive, doesn’t mean that it won’t let you use variables with a casing convention that conveys meaning.

Case preservation is what creates readable code, not case sensitivity. I write VB.Net every day and we have strict case conventions. We catch violations through code reviews just like everyone else does. Writing in C# doesn’t automatically cause developers to adhere to sane case conventions.

There is no case, other than using case to distinguish between variables, where an identical casing convention cannot be followed in a case insensitive language. You can write C# in all lowercase if that floats your boat (except for calls to the framework). You’d be just as much of an idiot to do it in C# as VB.

Let me repeat – the only case where case sensitivity has an actual end-effect is the where two variables are distinguished only by case. Since this is a practice not recommended by Microsoft, there is actually no likely case where there will be a functional difference. Also, since VB is case-preserving, there is no case convention that is not allowed or not preserved (other than the affore mentioned not recommended practice).

The only difference is that a case typo is auto-fixed in the VB IDE and caught by the compiler in C#. If you make a legitimate typing mistake in either language, it won’t compile. Learn ctrl-space and you will never make either a casing or a typing mistake. The only reason case insensitivity hasn’t been removed from modern compiled languages is that is pretty much doesn’t matter any more. Since case sensitivity has traditionally been there in C type languages and removing it will cause a lot of code to not be directly reusable, the minimal costs of changing it outweigh the almost unmeasurably small benefits of getting rid of it.

140

it makes no sense.
but yes, I guess it is a religious issue as the comments I am getting here http://stackoverflow.com/questions/895423/case-sensitive-vs-insensitive-syntax are not to the point, but with lots of emotions.