Ambiguities

[Stan Brown, Oak Road Systems]

In article <862 at gtenmc.UUCP>, csp at gtenmc.UUCP (Charudutta S. Palkar) writes:

>>>	 b )      a = a - ( b = ( a = a + b ) - b );
>>                      ^
>>??? Is there any way you can guarantee the value of the marker 'a'?

[... some deletions for brevity]
> 
>    Some may get the impression I am for cryptic code. No I am not
>    for cryptic code but for use of the language with all its features.
>    If some programmers cannot use its features they might as well
>    stop using it.
> 
>    C S Palkar

I disagree.  When I was in college a popular game was to write an
assembler program that used every instruction opcode at least once.
Could such a program be written, to illustrate "use of the language with
all its features"?  Of course?  Was it of any earthly use, _especially_
in a commercial environment?  Of course not.

Dangerous in a programmer is the temptation to use a feature simply
because it is there.  Sort of like an house builder who puts a sink in
the living room simply because he's got an extra sink lying around. 

Code that is not clear is bad code.  Code that uses "the language with
all its features" simply for the sake of using features is almost
certain to be cryptic code (and therefore, IMNSHO, bad code).  I don't
care whether it does whether its author intended.  You can be certain 
that no one else will be able to maintain it correctly--and that
includes the original author after a lapse of a few weeks or months.

On one of the more successful projects I was part of, every source
module was reviewed before it was allowed into the integration builds. 
Code that the reviewer couldn't understand after reasonable effort was
required to be rewritten.  (Sometimes, in the name of time pressure,
that requirement was relaxed.  Guess where the system bugs showed up?)

>From the fact that you have to ask the question, can we infer that _you_
can not with confidence use the language "with all its features"?  By
your own statement does that mean you "might as well stop using it"?  I
don't think so.  I think a more reasonable approach is to say that some
features in the language are generally better understood than others. 
Where there are two (or more) ways to accomplish a desired result, we
should be careful to choose the way that is likely to be most generally
understood.

If a programmer regularly uses && for & and doesn't understand the
difference between = and == then I would agree he or she needs help
fast--and that help might be in the form of career counseling.

But I personally would give high marks in a job evaluation to anyone who
choked on monstrosities like the presented above, and would argue for
the discharge of anyone who, after repeated warnings, persisted in
writing needlessly and egregiously obscure code.


Stan Brown, Oak Road Systems, Cleveland, Ohio, U.S.A.         (216) 371-0043
The opinions expressed are mine. Mine alone!  Nobody else is responsible for
them or even endorses them--except my cat Dexter, and he signed the power of
attorney only under my threat to cut off his Cat Chow!