ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) (04/08/88)
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