🚀 go-pugleaf

>>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.
>
>It is how it is used that can cause problems.  If someone names two variables
>I and i, he should expect that you, reading his program later,  would get
>quite confused.  >>Naming conventions<< let you use the power of the case
>sensitivity safely.
>
>If I have a naming convention that ...
>                                                ..., then as long as a
>programmer follows the rules no one will get confused.  BUT, if
>the language is case insensitive, the programmer will start ignoring the
>naming conventions because the compiler lets her, and the situation is just as
>bad as a case sensitive with no conventions and variables I and i.
>
>The case usage of a token can be used to convey information that is available
>elsewhere, but is more convenient to redundantly convey as upper/lower
>case letters.  The name WriteString is obviously a procedure (based on
>most naming conventions).  What is writestring?  Is it a variable
>containing the string that is going to be written out?  Is it a boolean
>deciding if a string should be written?    The language should let you
>pick naming conventions and then help enforce them.  A case insensitive
>language cannot help enforce naming conventions like the ones I describe.
>
>Bill Smith
>pur-ee!uiucdcs!wsmith
>wsmith@a.cs.uiuc.edu

     This posting seems to confuse two issues.  1) The desirability
of a set of conventions for encoding extra meaning into token names by
means of upper and lower case distinctions.  2) Case sensitive languages
are useful tool for enforcing such conventions.
     I am ambivalent about 1).  I have used case conventions on a few
personal projects and am not sure of the results.  But even if we --
for the sake of argument -- grant the first point, I am doubtful of the
second.
     The _ONLY_ useful tool for enforcing case naming conventions (or
any other programming conventions) is the code walk-thru or code
review.  Case sensitive languages are at best a mixed blessing in this
regard.  The CSL can help to enforce the group's standards ONLY with
regard to external names and names that occur in included code
fragments (if the language supports such).  The CSL will enforce that
WriteString <> writestring <> WRITESTRING, but for local names it will
be as happy to use one as another.
     The poster claims the WriteString is "obviously"  a procedure
name.  He may work in an area where case conventions make is obvious,
but such conditions are far from universal.  To me WriteString is
'obviously' a procedure name only because I have dabbled in Modula-2
where it is the name of a 'standard' procedure (in the InOut module).
I have three books on Modula-2 (Wirth, Gleaves, and Beidler &
Jackowitz), and from none of them can I infer any convention by which I
could deduce that WriteString is a procedure.  Indeed, the code
fragments and examples in these three books show no convention
whatsoever in the use of case; I can find example procedure names in
mixed case, all lower case and all upper.  If "WriteString" is
'obviously' a procedure name, what about "ALLOCATE?"  It too is a
'standard' Modula-2 procedure!
     This, of course, is the down side of attempting to use the case
sensitivity of the language to enforce your own coding standards.  The
rest of the world -- including those supplying your language's standard
library -- may have different conventions that you do.  Your
conventions may say the procedure ought to be called "Allocate", but
the language will enforce "ALLOCATE".  (Unless, of course, you want to
rewrite all of the standard library -- and any other 'foreign" code --
that does not conform.)
    With the case insensitive language you don't have this particular
problem.  You can call "Allocate" and "DeAllocate" without regard to
the fact that your vendor thought of them as "ALLOCATE" and
"DEALLOCATE".
     Thus, the CSL cannot enforce your case conventions for local
names.  It can (sort of) enforce them for external names, but this
seems to be a mixed blessing at best.  As you are going to need code
reviews to enforce your conventions for local variables, maybe you
really would be happier with a case insensitive language after all.

Carrington Dixon
UUCP: {convex, killer} mic!d25001