The Elements of Programming Style: Difference between revisions

Revision as of 22:25, 2 December 2019

Revision as of 12:50, 1 June 2020

Line 47:

'''''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 [[William Strunk Jr.|Strunk]] & [[E. B. White|White]] and is considered a practical template promoting [[Edsger Dijkstra|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).

Line 53:

==Lessons==

Its lessons are summarized at the end of each section in [[Aphorism|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.

Line 68:

# 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.

Line 99:

# 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.