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 Designing Applications for the Power Macintosh. All of them are useful whatever your target machine. One of my favorites is:
5. Avoid programming cleverness. Instead, assume a good compiler and write readable code.
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:
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.
This has been my experience with every large program or set of programs I've written, too. I know 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 small efficiencies and premature optimization. Robbins and Avitzur's advice also has a user-centered dimension.
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.
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. -----