Elements of Programming Style
From: https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style
The Elements of Programming Style
by Brian W. Kernighan and P. J. Plauger, is a study of programming style,
advocating the notion that computer programs should be written not only to
satisfy the compiler or personal programming "style", but also for
"readability" by humans, specifically software maintenance engineers,
programmers and technical writers. It was originally published in 1974.
The book pays explicit homage, in title and tone, to The Elements of Style,
by Strunk & White and is considered a practical template promoting Edsger
Dijkstra's structured programming discussions. It has been influential and has
spawned a series of similar texts tailored to individual languages, such as The
Elements of C Programming Style, The Elements of C# Style, The Elements of
Java(TM) Style, The Elements of MATLAB Style, etc.
The book is built on short examples from actual, published programs in
programming textbooks. This results in a practical treatment rather than an
abstract or academic discussion. The style is diplomatic and generally
sympathetic in its criticism, and unabashedly honest as well— some of the
examples with which it finds fault are from the authors' own work (one example
in the second edition is from the first edition).
Lessons
Its lessons are summarized at the end of each section in pithy maxims, such
as "Let the machine do the dirty work":
- Write clearly – don't be too clever.
- Say what you mean, simply and directly.
- Use library functions whenever feasible.
- Avoid too many temporary variables.
- Write clearly – don't sacrifice clarity for efficiency.
- Let the machine do the dirty work.
- Replace repetitive expressions by calls to common functions.
- Parenthesize to avoid ambiguity.
- Choose variable names that won't be confused.
- Avoid unnecessary branches.
- If a logical expression is hard to understand, try transforming it.
- Choose a data representation that makes the program simple.
- Write first in easy-to-understand pseudo language; then translate into
whatever language you have to use.
- Modularize. Use procedures and functions.
- Avoid gotos completely if you can keep the program readable.
- Don't patch bad code – rewrite it.
- Write and test a big program in small pieces.
- Use recursive procedures for recursively-defined data structures.
- Test input for plausibility and validity.
- Make sure input doesn't violate the limits of the program.
- Terminate input by end-of-file marker, not by count.
- Identify bad input; recover if possible.
- Make input easy to prepare and output self-explanatory.
- Use uniform input formats.
- Make input easy to proofread.
- Use self-identifying input. Allow defaults. Echo both on output.
- Make sure all variables are initialized before use.
- Don't stop at one bug.
- Use debugging compilers.
- Watch out for off-by-one errors.
- Take care to branch the right way on equality.
- Be careful if a loop exits to the same place from the middle and the
bottom.
- Make sure your code does "nothing" gracefully.
- Test programs at their boundary values.
- Check some answers by hand.
- 10.0 times 0.1 is hardly ever 1.0.
- 7/8 is zero while 7.0/8.0 is not zero.
- Don't compare floating point numbers solely for equality.
- Make it right before you make it faster.
- Make it fail-safe before you make it faster.
- Make it clear before you make it faster.
- Don't sacrifice clarity for small gains in efficiency.
- Let your compiler do the simple optimizations.
- Don't strain to re-use code; reorganize instead.
- Make sure special cases are truly special.
- Keep it simple to make it faster.
- Don't diddle code to make it faster – find a better algorithm.
- Instrument your programs. Measure before making efficiency changes.
- Make sure comments and code agree.
- Don't just echo the code with comments – make every comment count.
- Don't comment bad code – rewrite it.
- Use variable names that mean something.
- Use statement labels that mean something.
- Format a program to help the reader understand it.
- Document your data layouts.
- Don't over-comment.
Modern readers may find it a shortcoming that its examples use older procedural
programming languages (Fortran and PL/I) that are quite different from those
popular today. Few of today's popular languages had been invented when this
book was written. However, many of the book's points that generally concern
stylistic and structural issues transcend the details of particular languages.
Reception
Kilobaud Microcomputing stated that "If you intend to write programs to be
used by other people, then you should read this book. If you expect to
become a professional programmer, this book is mandatory reading".[1]
References
Reeves, Jack W. (January 1980). "The Elements of Programming Style".
Kilobaud Microcomputing. p. 9. Retrieved 23 June 2014.
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style,
McGraw-Hill, New York, 1974. ISBN 0-07-034199-0
B. W. Kernighan and P. J. Plauger, The Elements of Programming Style 2nd
Edition, McGraw Hill, New York, 1978. ISBN 0-07-034207-5