[antlr-interest] wow; talk about premature optimization

[Bryan Ewbank]

Brian Kernighan's Programming Style Tips
   1. Say what you mean, simply and directly.
   2. Use the ``telephone test'' for readability.
   3. Write clearly - don't be too clever.
   4. Don't use conditional expressions as a substitute for a logical
expression.
   5. Parenthesize to avoid ambiguity.
   6. Each time you make a test, do something.
   7. Follow each decision as closely as possible with its associated action.
   8. Use the good features of a language; avoid the bad ones.
   9. Capture regularity in control flow, irregularity in data.
  10. Each module should do one thing well.
  11. Make sure comments and code agree.
  12. Don't just echo the code with comments - make every comment count.
  13. Don't comment bad code - rewrite it.
  14. Use symbolic constants for magic numbers.
  15. Watch out for side effects and order of evaluation.
  16. Macros are not functions.
  17. Watch out for off-by-one errors.
  18. Test programs at their boundaries.
  19. Program defensively.
  20. Make sure input cannot violate the limits of the program.
  21. Make it right before you make it faster.
  22. Keep it right when you make it faster.
  23. Don't sacrifice clarity for small gains in ``efficiency.''
  24. Don't stop with your first draft.

[From The Elements of Programming Style, Kernighan & Plauger, McGraw-Hill, 1978]

Rob Pike's Rules Regarding Complexity

Most programs are too complicated - that is, more complex than they
need to be to solve their problems efficiently. Why? Mostly it's
because of bad design, but I will skip that issue here because it's a
big one. But programs are often complicated at the microscopic level,
and that is something I can address here.

   1. You can't tell where a program is going to spend its time.
Bottlenecks occur in surprising places, so don't try to second guess
and put in a speed hack until you've proven that's where the
bottleneck is.
   2. Measure. Don't tune for speed until you've measured, and even
then don't unless one part of the code overwhelms the rest.
   3. Fancy algorithms are slow when n is small, and n is usually
small. Fancy algorithms have big constants. Until you know that n is
frequently going to be big, don't get fancy. (Even if n does get big,
use Rule 2 first.)
   4. Fancy algorithms are buggier than simple ones, and they're much
harder to implement. Use simple algorithms as well as simple data
structures.
   5. Data dominates. If you've chosen the right data structures and
organized things well, the algorithms will almost always be
self-evident. Data structures, not algorithms, are central to
programming.