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: 11440e,23963231b5359f74 X-Google-Attributes: gid11440e,public X-Google-Thread: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-ArrivalTime: 2001-06-05 16:07:26 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!sn-post-02!sn-post-01!supernews.com!news.supernews.com!not-for-mail From: Pete Thompson 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: Tue, 05 Jun 2001 16:08:23 -0700 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.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> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ruby:10410 comp.lang.ada:8203 comp.lang.awk:2799 comp.lang.clarion:21165 comp.lang.java.programmer:73889 comp.lang.pl1:791 comp.lang.vrml:3529 Date: 2001-06-05T16:08:23-07:00 List-Id: On Tue, 5 Jun 2001 16:47:36 -0400, "Marin David Condic" wrote: >My comment is WRT "terse" for the sake of "terse". If the goal is >"readability" then it is yet to be demonstrated to my satisfaction that >"terse" serves this goal. As has been noted elsewhere, APL and assembly Hmm in that case, I should give you my sister's phone number. She can talk for well over two hours on the phone before finally getting to the point :) I feel the same way about code: being verbose is all well and good, but pointless verbosity can do more harm than good. It tends to hide the overall picture as to what the function/application is *really* doing. It makes the function look more complicated than it really is. It leaves you wondering if you're somehow missing something because there's more to read than is really necessary. As Roedy mentioned in some other message, it's a hard one to pin down since it's such a subjective matter. Maybe it's futile to even try. >language could both be described as "terse" and neither is typically held up >as an example of how to produce "readability". If one would contend that >"terse" serves "readability" I would ask to see some kind of study backing >up that claim - complete with a definition of what counts as "terse" and >what is simply "cryptic". Perhaps it'd help by using a thesaurus? Good terse: clear summary, concise, succinct. Bad terse: hidden, cryptic, magical. Good verbosity: descriptive, explanatory. Bad verbosity: tedious, rambling, long-winded. Which one of the following do you prefer: i = i + 1; or i equals i plus one. Imagine a whole program written using the latter method. Would that really be much fun to read? Compound statements would be nearly unreadable. >Granted, there are some shorthand notations within any given language that >the cognosenti immediately recognize. This might lead them to believe that >their shorthand is thus more "readable". What they are really seeing is the >fact that it is their familiarity with the idiom that makes it readable - in >the same way that a program I spend weeks building & massaging is more >"readable" than the one someone just now dumped in my lap. True. After all, a mathematical formula may seem cryptic to the average layperson, but it's immediately readable by other mathematicans. >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). There has to be a cut-off point where a certain number of knowledge and experience is required from new programmers, though. If they don't meet that requirement, then they shouldn't have been hired in the first place. After all, it's not *my* problem if someone doesn't know what a modulus operator is. >As for "terse for the sake of being cryptic" - that's obviously A Bad Thing. >My contention is that some programmers are terse for the sake of being >cryptic without really realizing that this is what they are doing. As >cognosenti they derive satisfaction from having what seems cryptic to the >outsider seem intuitively obvious to them. They may remark "....Well any >*competent* XXX programmer would understand this code at a glance!..." It >makes them feel good that they (and the rest of the in-crowd) must be >"better" than the unwashed masses. Well, that's sort of going to the extreme. If the syntax is a part of the language itself, then it should be readable by anyone well versed with the language. "i++" is not cryptic since that's a part of the language. If it's a "clever" (ab)use of the language, then you may need to reevaluate what you're doing. I hate it when people try to cram 4 or 5 or more different things into the same line. I just love reading stuff like c = a+++++b. (not) My general convention is one or two instructions per line, if possible, and use generous amounts of whitespaces and brackets. >Me? I'd rather write unbelievably uncomplicated, uncryptic, un-terse code >(especially when using C) so that when I have someone less experienced, less >familiar or less gifted coming on to a project, they can pick it up as >absolutely quickly as is possible and have the minimum problems making >changes to the code. Why? A) it makes money for the stockholders. B) It >keeps them from asking me hundreds of questions and using up my day - thus >making more money for the stockholders. C) Its less likely they'll make a >mistake that ends up costing the company lots of money - again maximizing >shareholder value, D) Did I mention that it makes money for the >stockholders? :-) > >MDC I guess we're pretty much arguing the same thing at this point. My own contention is that there are programmers who are needlessly verbose that the code looks more complex than it really is. Of course, coming from a DirectX background, it's possible that I may be a little biased :)