case sensitivity

[Barry Margolin]

This discussion is losing its specificity to C, so I've directed
followups to comp.lang.misc.

In article <10182 at socslgw.csl.sony.JUNET> diamond at csl.sony.junet (Norman Diamond) writes:
>Come on Henry, you wouldn't want to have to distinguish identifiers named
>myFunc and myfunc, when reading someone else's code.  If you don't want to
>have myFunc map onto myfunc (i.e. not be synonymous) then suggest a require-
>ment that all occurences of an identifier be consistent in case, but it is
>silly to permit two distinct identifiers to differ only in case.

So long as such things are not used haphazardly, case differences can
be useful.  For instance, in a language that doesn't permit some kind
of delimiter (e.g. underscores or hyphens) in identifiers, it's
possible that there could be two procedures named ReAdjustOneToken and
ReadJustOneToken (I know, I'm stretching); case is being used as a
delimiter, and it's completely obvious which one is which (but
readjustonetoken would be a poor name for either).

At a previous place of employment, case distinctions were often part
of some developers' or groups' programming conventions.  For instance,
parameters to top-level procedures might be named P_xxx, while
parameters to internal procedures would be named p_xxx.  Another group
used uppercase prefixes and suffixes to indicate data type; e.g. fooP
would be a pointer to a foo (we used PL/I, which doesn't have typed
pointers), but foop would be something else (and foopP would be a
pointer to a foop).

I've used both case-sensitive languages and case-insensitive
languages.  They both have their advantages and disadvantages.  Case
distinction, if used carefully, can be a good tool.  It's easy to
ignore when you aren't concerned about the attribute it represents,
and easy to notice when you are.

Barry Margolin
Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar