ddb@mrvax.DEC (DAVID DYER-BENNET MRO1-2/L14 DTN 231-4076) (10/29/84)
I am against case distinction in variable names because people are taught while they learn to read English that capitalization is a matter of style, not a matter of content (yes, there are places in English where capitalization can be construed to change the meaning, but darned few). I continually find, when reading C code, that I have ignored the case of variable names, and have to go back and check to see if the things I've been thinking were the same, really are. -- David Dyer-Bennet -- ...decwrl!dec-rhea!dec-mrvax!ddb
wagle@iuvax.UUCP (11/01/84)
Okay, now you go try to transport a 32,000 line program that spells the same keyword/variable: Procedure PROCEDURE procedure or myvar MYvar MyVar myvar and go try to locate all occurrances with a low IQ editor.
gino@voder.UUCP (Gino Bloch) (11/03/84)
[EAT eat EAT eat EAT eat EAT eat EAT eat EAT eat EAT] > I am against case distinction in variable names because people are > taught while they learn to read English that capitalization is a matter > of style, not a matter of content (yes, there are places in English > where capitalization can be construed to change the meaning, but > darned few). I continually find, when reading C code, that I have > ignored the case of variable names, and have to go back and check to > see if the things I've been thinking were the same, really are. > > -- David Dyer-Bennet > -- ...decwrl!dec-rhea!dec-mrvax!ddb 1. C is not English 2. This is an automatic way to break LOTS (also lots) of code -- Gene E. Bloch (...!nsc!voder!gino)
henry@utzoo.UUCP (Henry Spencer) (11/04/84)
This is a problem with the customer, not the language. A programmer
who names two different variables "foo" and "Foo" should be fired at
once, for incompetence. [The same applies if he names two different
programs "mail" and "Mail". Grrr.]
When the two names are "foo" and "FOO", the situation is not so clear.
These two usages normally are *not* interchangeable in English, and
one can argue that they should be considered to be distinct.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryguido@mcvax.UUCP (Guido van Rossum) (11/06/84)
In article <9500013@iuvax.UUCP> wagle@iuvax.UUCP writes: > Okay, now you go try to transport a 32,000 line program that spells the >same keyword/variable: > [...] >and go try to locate all occurrances with a low IQ editor. Don't try to offload the braindamage of your particular editor to the C standard. Write your own editor! (C was originally conceived only for writing editors. :-) -- Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido@mcvax.UUCP "The number of arguments is unimportant unless some of them are correct."
aeb@turing.UUCP (11/07/84)
>> Okay, now you go try to transport a 32,000 line program that spells the >> same keyword/variable: >> [...] >> and go try to locate all occurrances with a low IQ editor. > Don't try to offload the braindamage of your particular editor > to the C standard. Write your own editor! (C was originally > conceived only for writing editors. :-) Of course things are worse than you might think - this 16,000 line program you got contains modules that automatically generate pieces of source code for other modules (Guido, you know what program I am thinking of). Now a smart editor won't help you; if you have a monocase 6 significant char compiler/loader and you want this program then you'll have to write a preprocessor to convert/compress identifiers. -- Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aeb
bsa@ncoast.UUCP (Brandon Allbery) (11/09/84)
One other comment on the inadvisability of 6-character uppercase externs:
****************** ANSI COMMITTEE, PLEASE LISTEN ********************
So doing will make ``ANSI Standard C'' ***incompatible*** with Berkeley
(and other major, i.e. System V) C. Which forms of C constitute the
vast majority of C programs, even in their non-Unix-specific programs.
Put that braindamage in C, and you lose all the benefits of having C.
Use something else instead; don't waste your time.
--bsa
--
Brandon Allbery @ North Coast Xenix | the.world!ucbvax!decvax!cwruecmp!
6504 Chestnut Road, Independence, Ohio | {atvax!}ncoast!{tdi1!}bsa
(216) 524-1416 \ 44131 | E1439@CSUOHIO.BITNET (friend's acct.)
---------------------------------------+---------------------------------------
`Confusion is my natural state.'rick@uwmacc.UUCP (the absurdist) (11/10/84)
> Okay, now you go try to transport a 32,000 line program that spells the > same keyword/variable: > [...] > and go try to locate all occurrances with a low IQ editor. Fine: you give me a program that is 32,000 lines long and uses capitalization as a way of distinguishing variables and try and maintain it! Given the wealth of information concerning the difficulty of programmers making distinctions between similarly spelled variable, why do language designers insist on giving us these damn case-sensitive languages, which make it even more difficult to distinguish variables than before? Modula-2 is a prime candidate for offensiveness here; for a language written by someone who is concerned with program correctness to have such a large hole in it seems wrong-headed in the extreme. Ditto for short variable names. Please, no comments on long variable vs. short: we all know that long names break programs & short names are unreadable. The real question is how long are we going to put up with this crap in NEW languages. The old ones will never be fixed. :wq -- Rick Keir -- MicroComputer Information Center, MACC 1210 West Dayton St/U Wisconsin Madison/Mad WI 53706 {allegra, ihnp4, seismo}!uwvax!uwmacc!rick
guido@mcvax.UUCP (Guido van Rossum) (11/12/84)
In article <455@uwmacc.UUCP> rick@maccunix.UUCP (Rick Keir) writes: >Fine: you give me a program that is 32,000 lines long and uses capitalization >as a way of distinguishing variables and try and maintain it! > Given the wealth of information concerning the difficulty of programmers >making distinctions between similarly spelled variable, why do language >designers insist on giving us these damn case-sensitive languages, which >make it even more difficult to distinguish variables than before? All the flames about case-sensitivity seem to assume that programmers randomly use variables Foo, fOo, FOO and foo. This would surely be antiproductive (when the variables have overlapping scopes). But in actual programming, case is mostly used to flag different types of identifiers: since the "dark ages" of unix, FOO used to be a macro (manifest constant) or typedef, and foo a variable of function. There are other, similar conventions that greatly HELP the programmer by hinting about certain properties of identifiers: Gosling's Emacs uses FooBar for external Functions. -- Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam, Holland guido@mcvax.UUCP "Life is like a sewer. What you get out of it, depends on what you put into it."
henry@utzoo.UUCP (Henry Spencer) (11/13/84)
> One other comment on the inadvisability of 6-character uppercase externs: > ... > So doing will make ``ANSI Standard C'' ***incompatible*** with Berkeley > (and other major, i.e. System V) C. Which forms of C constitute the > vast majority of C programs, even in their non-Unix-specific programs. How quickly some of us forget the bad old days... The vast majority of C programs were written before *anybody* implemented arbitrary-length names. Most C programs date from environments with either a 7-character limit or a 6-character limit (Unix and non-Unix environments respectively). -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry