The Elements of Programming Style [Paperback]

Brian W. Kernighan (Author), P. J. Plauger (Author)

Product Details

• Paperback: 168 pages
• Publisher: Computing Mcgraw-Hill; 2 edition (January 1, 1978)
• Language: English
• ISBN-10: 0070342075
• ISBN-13: 978-0070342071
• Product Dimensions: 8.9 x 5.9 x 0.3 inches
• Shipping Weight: 8 ounces
• Average Customer Review: 4.3 out of 5 stars  See all reviews (17 customer reviews)
• Amazon Best Sellers Rank: #851,906 in Books (See Top 100 in Books)

Most Helpful Customer Reviews

28 of 30 people found the following review helpful

5.0 out of 5 stars All programmers should buy this book October 13, 2001

By A Williams VINE™ VOICE

Format:Paperback

I firmly believe that computer programming is a craft, perhaps an art but certainly not a science. As you learn the craft you need to learn the wisdom of those that have gone before you. This book becomes essential.

It spells out, first with a counter example found in a piece of code published elsewhere and then with the code rewritten, over 70 pearls of wisdom that should be engraved into our consciousness; for many years every morning when I logged on to start work as a commercial Unix programmer one of these rules was randomly chosen as my message of the day, if I didn't understand the short rule I dragged out the book and refreshed my memory.

Brian Kernighan has co-authored three books almost essential to learning our craft, this volume, "Software Tools" and "The Unix Programming Environment". "Elements of Programming Style" spells out the fundamental rules, "Software Tools" shows you how to apply them to a number of simple projects and extends the rules to software design and finally "The Unix Programming Environment" shows you how to use them in an operating system designed to reward you for your effort.

The examples in either PL/I or Fortran expound the simple rules clearly and expertly in a manner typical of Kernighan's writing. That the languages used are old and most of the rules long accepted lore are not a drawback to this volume. Anyone who knows C, Pascal or even Perl should easily understand the code and programmers turn out code just as bad today in any number of languages.

These things make this book highly recommended reading for anyone who wishes to call them self "programmer." A final word of warning, don't lend this book to anyone, you'll never get it back - I've bought four copies so far.

12 of 12 people found the following review helpful

5.0 out of 5 stars A classic programming book February 15, 2001

By Daniel Mall

Format:Paperback

Published in 1978. 168 pages. These 77 rules represent the definitive basis of good programming style and best programming practices. Included in this famous set of rules are gems such as "say what you mean", "write clearly", "use the telephone test", "make sure comments and code agree", and "make it right before you make it faster". Each rule is described in the context of a small program or code fragment. The authors expertly illuminate their rules by correcting these deficient programs. All of the example code in FORTRAN or PL/I was taken from prior publications. The rules are programming language independent (76/77); the only exception is "avoid the FORTRAN arithmetic IF." This book solidified many of the ideals expressed in the structured programming movement.

7 of 7 people found the following review helpful

4.0 out of 5 stars Many rules still apply September 18, 2006

By alkmaar

Format:Paperback

I dare say many rules Mr. Kernighan preached almost three decades ago are still NOT followed by the programming community at large. For examples, "Modularize. Use subroutines." "Each module should do one thing well." and "Don't patch bad code--rewrite it." A widespread, bad practice of 90% of the programmers today is still writing functions that are way too long! And they very often keep modifying existing functions--inserting new logic into them--to make already bad code even worse; they seldom give it a second thought about rewriting the whole damn crap!

Another set of rules from the book: "Make sure code and comments agree." and "Don't over-comment." Many programmers seldom do the first thing, resulting in widespread mismatches between the actual codes and surrounding comments. This applies to Java code as well. The comment style recommended by Java--that is, mixing code and comments that can be extracted into so-called self documentation--is an outright violation of the "don't over-comment" rule. (This is intended to be a criticism of Java-style comments.) Good code should document itself clearly; with perhaps a little help from judiciously added few comments that are not self-evident from the code itself.

The book uses FORTRAN and PL/I code examples. There are things that no longer apply today. But the fundamental rules and styles are still well applicable today and in the future.