Because maintenance is so important and so expensive, write
programs as if the most important communication they do is not to the
computer that executes them but to the human beings who will read and
maintain the source code in the future (includingyourself).
In the Unix tradition, the implications of this advice go beyond
just commenting your code. Good Unix practice also embraces choosing
your algorithms and implementations for future maintainability. Buying a
small increase in performance with a large increase in the complexity
and obscurity of your technique is a bad trade — not merely because
complex code is more likely to harbor bugs, but also because complex
code will be harder to read for future maintainers.
Code that is graceful and clear, on the other hand, is less
likely to break — and more likely to be instantly comprehended
by the next person to have to change it. This is important,
especially when that next person might be yourself some years down the
Never struggle to decipher subtle code three times. Once might
be a one-shot fluke, but if you find yourself having to figure it out
a second time — because the first was too long ago and you've
forgotten details — it is time to comment the code so that the
third time will be relatively painless.