From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10ad19,23963231b5359f74 X-Google-Attributes: gid10ad19,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 11440e,23963231b5359f74 X-Google-Attributes: gid11440e,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-06 09:28:52 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!news-out.visi.com!hermes.visi.com!pulsar.dimensional.com!dimensional.com!coop.net!newsfeed1.global.lmco.com!svlnews.lmms.lmco.com!news1.lmtas.lmco.com!not-for-mail From: Gary Scott Newsgroups: comp.lang.ruby,comp.lang.ada,comp.lang.awk,comp.lang.clarion,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml Subject: Re: Long names are doom ? Date: Wed, 06 Jun 2001 10:26:11 -0500 Organization: LM Aeronautics Message-ID: <3B1E4B93.7FB8A94D@lmtas.lmco.com> References: <83WP6.3874$yc6.728572@news.xtra.co.nz> <3B1411D0.3AAF42E7@ftw.rsc.raytheon.com> <9f2nks$ibd$0@dosa.alt.net> <3B177EF7.2A2470F4@facilnet.es> <9f8b7b$h0e$1@nh.pace.co.uk> <9f8r0i$lu3$1@nh.pace.co.uk> <9fgagu$6ae$1@nh.pace.co.uk> <9fjgha$blf$1@nh.pace.co.uk> <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com> <3B1E1452.BAFAAB7F@baesystems.com> NNTP-Posting-Host: CAA261517.lmtas.lmco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {C-UDP; LMTAS} (WinNT; U) X-Accept-Language: en,pdf Xref: archiver1.google.com comp.lang.ruby:10429 comp.lang.ada:8243 comp.lang.awk:2823 comp.lang.clarion:21225 comp.lang.java.programmer:74117 comp.lang.pl1:817 comp.lang.vrml:3560 Date: 2001-06-06T10:26:11-05:00 List-Id: Hi, "Readability" can be far better achieved through the proper use of comments. While variable names should be "understandable" (you decide what that means), the implication that variables/procedure/class/member/etc names must be full english words is a red herring. The CODE does not necessarily need to be so obsessively verbose, the commentary needs to be verbose (or "sufficiently" so). David Gillon wrote: > > Pete Thompson wrote: > > > >In my estimation, the issue of "readability" is far more important for > > >someone *new* to a project and/or *new* to the language. Can they walk in > > >the door and get up to speed more quickly (thus making more money for the > > >stockholders) if we rely on "terse" languages/notations or will they become > > >productive faster if the language/notations are more verbose, rely less on > > >non-obvious semantics, have better comments, etc.? > > > > Hmm.. I'd have to say that I agree and disagree. It really depends on what > > industry you're in. If you're in the kind of industry where you're hiring > > newbie programmers all the time, then yes, it's important to be as explicit as > > possible. However, there are industries where programmers MUST be experienced > > before they're hired. Does it really make sense to make your code as > > newbie-ish as possible for them? (Again, without being cryptic). > > Explicit, readable coding has value even when being read by the most > experienced of software engineers. Consider the case of a safety > critical system under review by an external auditor prior to > certification. It's vital he be able to review the system in as thorough > a manner as possible in the time available, yet he may be completely new > to your coding standards and practices. The logic of a decision needs to > be clearly laid our for him, not something he needs to delve into the > musty depths of obscure documents for or to seek information on from the > original coder (especially if the original coder is in a substantially > different timezone). Equally, someone may have to fix your code twenty > years down the tracks, when the original coding team and the rationale > behind their decisions may have long since vanished (or walked in front > of a bus...). > > Explicit pays, maybe not now, maybe not directly, but in the end its a > worthwhile investment. > > -- > > David Gillon