🚀 go-pugleaf

In article <2640@cognos.UUCP> roberts@cognos.UUCP (Robert Stanley) writes:
>So what?  We are all entitled to our own views and idiosyncrasies, but we
>are typically paid to produce working, understandable, flexible,
>maintainable, etc. code.  If in doubt, make the computer pick up the slack.
>It doesn't take much effort to adapt one of today's editors/browsers to
>using a name alias table, or to make global changes to names in a compile
>unit via a name substitution list....
exactly
>... every so often I find that my style is at odds with local 
>convention/standards.  When this happens, I can .. build a transformer
>which will massage my (consistent) code into the required local format.
Better yet for the programming environment to handle the transformation.
...
>Ummm, don't you think we've about bashed this subject to death?
Not yet.  A parallel discussion has been going on in comp.lang.smalltalk,
and I posted the following note: (with minor reformatting changes --  text
that missed the first posting is added between {})

Path: PT.CS.CMU.EDU!IUS3.IUS.CS.CMU.EDU!ralphw
From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
Newsgroups: comp.lang.smalltalk
Subject: Re: embeddedCapitals
Message-ID: <1229@PT.CS.CMU.EDU>
Date: 25 Mar 88 21:15:59 GMT
References: <2472@pdn.UUCP> <12100008@osiris.cso.uiuc.edu>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 31

In article <12100008@osiris.cso.uiuc.edu> goldfain@osiris.cso.uiuc.edu writes:
>
>Now that I've thought about it for a bit, I think there is no solution to the
>embedded-capitals-causes-naming-errors problem.  Anything you do to improve
>readability will cause possible name-matching  errors, whether you separate
>parts of long names with spaces, underscores, capitals, etc.
This is exactly why the name separator stuff might best be handled by a {good}
programming environment, not the compiler/interpreter itself.  A potential
drawback is that {in a naive implementation} you might end up limiting {the
number of usable characters by reserving too many characters as attribute 
descriptors, like how Scribe tends to reserve @ and (, and Tex \}
For example, if uppercase is 'reserved' bu the programming environment as a
possible 'long-word-separator' attribute, then you may lose the ability to use
uppercase in {representing} program symbols. [but maybe these should be 
represented internally by something other than character strings anyway, like
a tagged number (so that the intepreter/compiler doesn't have to do parsing in
addition to its other duties).]

Ideally, the user preference could be whatever they're most comfortable with,
so a symbol displays as AVeryLongWord to users who prefer that style, or 
a_very_long_word, or just averylongword for those with a lot of patience.

Comments?
--
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA


-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA