 |
Reinforcement Learning and
Artificial
Intelligence (RLAI)
|
Aphorisms on programming style
|
This page is part of a larger discussion of programming style. The ambition
of this page is to list pithy statements of opinion from some leading
and not-so-leading lights in computer science and literature.
Please add your own aphorisms, or comment on those here.
Readability
The keys to good software are clarity, humility, and readability.
The most important of these is readability.
"Programs must be written for people to read, and only incidentally for machines to execute."
- Abelson & Sussman, SICP, preface to the first edition
"The essence of good programming
style is communication. Good style in programming is roughly as
difficult to learn as good style in English. In both cases, the
document has no value if it does not convey its meaning to the reader."
"Any fool can write code that a computer can understand.
Good programmers write code that humans can understand."
- Martin Fowler, Refactoring: Improving the Design of Existing Code
Brevity
Generally speaking, less is more. The less new stuff a reader of your code has to understand, the better it is.
Fewer characters is not the same as more readable code, but it usually helps.
"Length is not a virtue in a name;
clarity of expression is. ... When the variable names are
huge, it's harder to see what's going on."
- Rob Pike
"None ever wished it longer than it is."
- Johnson on Paradise Lost
Performance
"
Premature optimization is the root of all evil (or at least most of it) in programming."
- Donald Knuth
"
The key to performance is elegance, not battalions of special cases."
- Jon Bentley and Doug McIlroy
"
Measure. Don't tune for speed until you've
measured, and even then don't unless one part of the code
overwhelms the rest."
"
Fancy algorithms are buggier than simple ones"
- Rob Pike
Documentation
"
Rather than trying to document how
you perform a complex algorithm, try to make the algorithm easier to
read by introducing more identifiers."
- Paul Wheaton
"
...remember that terseness is a
virtue.
A smaller body of words is easier to comprehend.
When documenting a program, say only what needs to be said without
leaving important things out.
For example, the following comment is not informative:
count = count + 1 # Increase count by 1"
- ~Cliff Shaffer
"
keep comments brief and
bannerfree. Say what you want to say in the program, neatly
and consistently. Then move on."
[on comments] "
A delicate matter, requiring taste and judgment. I
tend to err on the side of eliminating comments, for several
reasons. First, if the code is clear, and uses good type
names and variable names, it should explain itself."
"
...basically, avoid comments. If your code needs a comment to be
understood, it would be better to rewrite it so it's easier
to understand."
- Rob Pike
On design
Get it about right the third time
This first implementation is too quick and dirty.
The second implementation is too fancy and general.
The third implementation is about right.
Then a design document is written,
leading to the final implementation.
"The best writing is rewriting."
- E. B. White
"But the audience is right. They're
always, always right. You hear directors complain that the advertising
was lousy, the distribution is no good, the date was wrong to open the
film. I don't believe that. The audience is never wrong. Never."
- William Friedkin, in a NYT interview
Miscellaneous
"Simple rule: include files should never include include
files."
- Rob Pike
