Case sensitive and ludicrous statements

[Douglas Alan]

Lulu of the Lotus-Eaters <mertz at gnosis.cx> writes:

> Douglas Alan <nessus at mit.edu> wrote previously:

> |If you are talking merely about putting constants, or somesuch, in all
> |upper case, then perhaps there is a significant minority that does do
> |If, on the other hand, you are referring to using StudlyCaps (aka
> |CamelCase) in a case-insensitive language, then we have a serious
> |disagreement.  I have read and written a lot of code in
> |case-insensitive languages, and I have never seen anyone code as you

> On the other hand, *I* have almost certainly read and written a lot more
> code in case-insensitive langauges than Douglas Alan has... and I found
> the use of case (both constants-in-caps and CamelCase) to be quite
> pervasive.  Certainly a large majority use the ALLCAP constant
> convention.  But a majority also use various mixed case conventions (not
> always consistent between programmers and/or languages, however).

> FWIW, doing the above is ALSO a GOOD idea, not just empirically true.

I certainly cannot speak as to whose experience of how the majority
programs, represents reality better, since neither of us is using a
statistically sound sampling method, but I *can* speak to whether it
is a good idea to use CamelCase in a type insensitive language:

It is clearly not!  CamelCase gives you no advantage (except perhaps
to save a few charactes in your identifiers) to using identifiers with
underscores or dashes, and it has the significant disadvantage that
apparently different identifiers, such as "eaTime" and "eatIME", will
be confounded by the language.  This is a sand-trap wating to snare
you, if you program this way in a case-insensitive language.

You will notice that CamelCase was extremely uncommon (if used at all)
before the advent of case-sensitive languages, and there is good
reason for this.  It didn't make sense then, and it doesn't make sense
now!  (In a case-insensitive language.)

|>oug