Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!texsun!texsun.central-relay.sun.com!convex!mic!authorplaceholder From: d25001@mic.UUCP Newsgroups: comp.lang.misc Subject: Re: case sensitivity Message-ID: <66700001@mic> Date: 15 Mar 88 05:03:00 GMT References: <2318@bsu-cs.UUCP> Lines: 88 Nf-ID: #R:bsu-cs.UUCP:2318:mic:66700001:000:4862 Nf-From: mic.UUCP!d25001 Mar 14 23:03:00 1988 >>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: !{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