C style (was: Efficient coding considered harmful?)
Doug Gwyn
gwyn at smoke.BRL.MIL
Sat Nov 12 14:23:01 AEST 1988
In article <764 at wsccs.UUCP> terry at 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.
More information about the Comp.lang.c
mailing list