TITLE: Assume a Good Compiler and Write Readable Code
AUTHOR: Eugene Wallingford
DATE: July 06, 2012  4:19 PM
DESC: 
-----
BODY:
Greg Robbins and Ron Avitzur, the authors of MacOS's original
Graphing Calculator, offer nine tips for
<A HREF="http://www.PacificT.com/Develop.html">
   Designing Applications for the Power Macintosh</A>.
All of them are useful whatever your target machine.  One of
my favorites is:

<BLOCKQUOTE><EM>
<B>5.  Avoid programming cleverness.  Instead, assume a good
compiler and write readable code</B>.
</EM></BLOCKQUOTE>

This is good programming advice in nearly every situation, for
all the software engineering reasons we know.  Perhaps
surprisingly, it is good advice even when you are writing code
that has to be fast and small, as Robbins and Avitzur were:

<BLOCKQUOTE><EM>
Cycle-counting and compiler-specific optimizations are favorite
pastimes of hackers, and sometimes they're important.  But we
could never have completed the Graphing Calculator in under six
months had we worried about optimizing each routine.  Rather,
we dealt with speed problems only when they were perceptible to
users.

We made no attempt to look at performance bottlenecks or at the
compiled code of the Calculator until after running execution
profiles.  We were surprised where the time was being spent.
Most of the time that the Calculator is compute-bound it's
either in the math libraries or in QuickDraw.  So little time
is spent in our code that even compiling it unoptimized didn't
slow it down perceptibly.  Improving our code's performance
meant calling the math libraries less often.
</EM></BLOCKQUOTE>

This has been my experience with every large program or set of
programs I've written, too.  I <EM>know</EM> where the code is
spending its time.  Then I run the profiler, and it shows me
I'm wrong.  Donald Knuth famously warned us against
<A HREF="http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize">
   small efficiencies and premature optimization</A>.

Robbins and Avitzur's advice also has a user-centered dimension.

<BLOCKQUOTE><EM>
Programmers are often tempted to spend time saving a few bytes
or cycles or to fine-tune an algorithm.  If the change isn't
visible to users, however, the benefits may not extend beyond
the programmer's satisfaction.  When most of the code in an
application is straightforward and readable, maintenance and
improvements are easier to make.  Those are changes that users
will notice.
</EM></BLOCKQUOTE>

We write code for our users.  Programmer satisfaction comes
second.  This passage reminds me of a lesson I internalized
from the early days extreme programming:  At the end of the day,
if you haven't added value for your customer, you haven't earned
your day's pay.
-----