Path: utzoo!attcan!uunet!husc6!mailrus!nrl-cmf!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: C style (was: Efficient coding considered harmful?)
Message-ID: <8864@smoke.BRL.MIL>
Date: 12 Nov 88 04:23:01 GMT
References: <3105@hubcap.UUCP> <34112@XAIT.XEROX.COM> <1700@dataio.Data-IO.COM> <7700@bloom-beacon.MIT.EDU> <764@wsccs.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 60

In article <764@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes:
>Unions should be avoided, as well as non-pre-aligned structures.

I don't know what you mean by a "non-pre-aligned" structure; perhaps
one with holes?  In any case, object alignment is implementation-
dependent and should not be a major concern when designing most
data structures.  Unions have obvious uses for which there is no
acceptable substitute, but one should not go out of one's way to
use a union where one is not required.

>	if( expression operator expression)
>rather than
>	if (expressionoperatorexpression)
>which can break old compilers with either the space after the if or ...

I have never seen a C compiler that had trouble with white space between
the "if" and "(" tokens.  If you insist on "if(" then at least balance
the white space adjacent to the parentheses.

>It is sheer stupidity to depend on the supposed contents of a black box; for
>instance, a compiler.  This generates non-portable and lazy coding practices
>"aw... the compiler'll make it fast..."

To the contrary, the example you quoted showed that non-portable practices
could be avoided without sacrificing efficiency, by relying on the
compiler to produce code optimized for the particular architecture.
If some compiler has a shortcoming in this regard, effort spent to
improve the compiler will have a larger payoff than effort spent in
tweaking individual applications in an attempt to partially compile
the code by hand in advance.

>Ability to understand others code is the difference between a programmer and
>a person who can program.  Writing code for idiots is only good if you are
>an idiot and can do no better, or if you are willing to hire idiots.

You miss the point.  Even the most experienced C programmer stands to
benefit, EVEN WHEN LATER WORKING ON HIS OWN CODE, if the code is
written with maintainability in mind.  The more low-level tricks
contained in a stretch of code, the less maintainable it is even
to the original programmer.

>There is some truth to this, but the key word is "unnecessary".  It is
>also unnecessary for a computer programmer, whose first abstract concept
>should have been bits.  If the person is a C programmer, the second an third
>concepts should have been Hexadecimal and Octal.  Assuming that these
>operations haven't become automatic after experience is silly.  It is equally
>silly to think of a programmer doing bit operations with multiplies instead of
>shifts!

Judging by the errors I have seen in literally millions of lines of C
code, the C programmer who thinks primarily in terms of bits is probably
introducing scads of present and future bugs into his code.

>You have any idea how long a multiply takes on most architectures?

Not normally long enough to worry about.

One should micro-optimize only those sections of code that need it,
when it is clear that the tradeoff against maintainability is worthwhile.
To do this for all source code would be making a poor long-term tradeoff.