Path: utzoo!mnetor!spectrix!John_M
From: John_M@spectrix.UUCP (John Macdonald)
Newsgroups: comp.lang.misc
Subject: Re: case sensitivity
Message-ID: <506@spectrix.UUCP>
Date: 15 Mar 88 03:17:46 GMT
References: <2318@bsu-cs.UUCP> <2758@csli.STANFORD.EDU>
Reply-To: jmm@spectrix.UUCP (John Macdonald)
Organization: Spectrix Microsystems Inc., Toronto, Ontario, Canada
Lines: 54

In article <2758@csli.STANFORD.EDU> kasper@csli.UUCP (Kasper Osterbye) writes:
>In article <2318@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>>Just an opinion:  case sensitivity in a programming language is not in
>>itself a bad thing.  It is how it is used that can cause problems.
>> --> [Arguments]
>>Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
>
>I disagree. Case sensitivity is always a drag. Someone always will use
>the TWO variables i and I, and I will get quite confused. I like a language
>to treat WriteString as the same identifier as writestring, but I like
>that I can write it both ways.

I would rather you used write_string or WriteString, but not writestring.
Whenever you are working in a language which does not permit _ (or . or
some other separator) as a legitimate character in an identifier, then
using capitalization to indicate internal breaks is neccessary, and case
insensitivity is DANGEROUS.  In the following (contrived) declarations:

integer     ForEd, ForSusan, ForWard;

integer     Backward, Forword;

you certainly get a shock when your two identifiers ForWard and Forward
conflict.  If the second is declared in a nested scope, there isn't
any error in many languages - just a nasty debugging problem.  Even if
your language does tell you about the conflict, how do you avoid such
conflicts?  In a large program, you end up having to define an official
standard naming convention used by eveyone on the project with central
control of the top level of the naming scheme to ensure that there is
no POSSIBLE overlap.

This sort of unexpected equivalence is especially prone to occur when
acronyms or abbrieviations are used as a portion of an identifier name.
For example, suppose Wildenwooly Research Institute designed an automotive
analysis program, containing the routines wriTestPiston, wriTestSpark,
wriTestValve, and wriTestRing.  The "wri" prefix distinguishes all of the
routines in their library, so that you are unlikely to get conflicts in
your own programs when you use this (they distributed it of the net, of
course).  You would get an interesting result if you included that module
in your program and tried to also use a call to that previously mentioned
WriteString.

Certainly someone can (mis-)use case sensitivity to avoid thinking of
descriptive meaningful names.  However, if both cases are being used,
then the person who wrote the code thinks it is sensitive (and sensible)
to use that specific case.  Why should a compiler throw away information
that someone had to deliberately provide?

If holding down the shift key is too much of "a drag", then convert
the programs which you are using to lower case (and live with any
conflicts you have thereby created).  Don't ask for compilers to
destroy useful distinctions.
-- 
John Macdonald   UUCP:    {mnetor,utzoo}             !spectrix!jmm