Path: utzoo!utgpu!watmath!clyde!att!ucbvax!bloom-beacon!athena.mit.edu!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Efficient coding considered harmful?
Message-ID: <8059@bloom-beacon.MIT.EDU>
Date: 19 Nov 88 09:58:32 GMT
References: <3105@hubcap.UUCP> <34112@XAIT.XEROX.COM> <1700@dataio.Data-IO.COM> <8630@smoke.ARPA> <1704@dataio.Data-IO.COM> <119@twwells.uucp> <7700@bloom-beacon.MIT.EDU> <137@twwells.uucp> <764@wsccs.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 76

Not surprisingly, I got ripped to shreds by Bill Wells and Terry
Lambert (among others) for having dared to suggest that good
style might be more important than raw efficiency and
microoptimization.  (Don't worry; this won't be a line-by-line
retribution; I've got better things to do.)

The reason I opened my earlier posting by casting "efficiency vs.
style" as a religious war was to suggest that I did not expect to
convince the efficiency aficionadoes that efficiency is not as
important as they think it is, any more than I expect them to
convince me that it is.  ("Efficiency aficionado" is not meant as
a pejorative term; some people simply have differing opinions
on the relative importance of things like efficiency and style.
The fact that these opinions are polarized and strongly held
makes for a fine religions war.)

There is an abominable quantity of horrible code in existence
today, and egregious amounts of time are wasted trying to fix
neverending bugs, trying to add seemingly reasonable features
which the "architecture" inexplicably prohibits, and finally
abandoning the whole mess and rewriting it from scratch.  I will
be vehemently disagreed with, but I submit that most of this
unmaintainable code arises out of misplaced concerns for
"efficiency."  It is true that there are a lot of miseducated
programmers out there, but their miseducation often derives from
teachers and textbook authors who constantly harp on efficiency
without teaching moderation, and from the badly-written code by
which they are surrounded and which they (the students)
inevitably emulate and go on to perpetuate.

I am not, repeat not, saying that efficiency is not important.  I
am not advocating (in this article, anyway) writing deliberately
inefficient code just to make it clearer.  I am saying that style
may be more important than efficiency, particularly since not all
programmers are able to "have their cake and eat it too."
Certainly we need to educate people in this direction; certainly
we need to teach them techniques for writing code that is right
the first time (where "right" is clean, clear, and not
inefficient).  When assigning priorities, though, I would rather
have people learn clarity and good style first, and efficiency as
the need arises.  (Among other things, the marketplace
imperatives of which we are endlessly reminded will ensure that
efficiency will not be neglected; while there are, sadly, not as
many incentives for writing clearly.)  The industry is not
plagued by slow programs (compilers being tuned for the
benchmarks to the contrary notwithstanding).  The industry is
plagued by software that is over schedule, over budget, buggy,
and unmaintainable.

Please: those who keep coming down like a ton of bricks (and no,
I don't take it that way; this is a religious war--I know I'm
right :-)) when it is even suggested that efficiency might not be
all-important: I am not saying that you are wrong, merely that
I'd like to shift the emphasis.  (I would have more sympathy,
though, with articles which claim they agree that style is
important while continuing to trot out obfuscated C contest
candidates, if they didn't doggedly insist that x<<1 is still
better than x*2, when it has been adequately shown that the
former contributes nothing to efficiency and can only detract
from readability.  Quit saying that not all compilers can do
these optimizations--to quite Kernighan and Plauger, "Those that
will not must certainly provide worse inefficiencies to worry
about.")

I forgot to recommend The Elements of Programming Style
(Kernighan and Plauger) in my previous article.  If you haven't
read it already, do so; and read it again if you have.  It's got
more solid, practical advice on good style on each page than
you'll see on the net in a year, and it's got a whole chapter on
efficiency, too (relegated to the back, where it belongs).  Don't
let the Fortran and PL/I throw you--with a little thought all of
the issues being discussed can be seen still to be supremely
important today.

                                            Steve Summit
                                            scs@adam.pika.mit.edu