Re: Long names are doom ?

[Pete Thompson <blackpete@nowhere.somewhere.anywhere.com>]

On Tue, 5 Jun 2001 16:47:36 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> 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  :)