Slashdot Mirror
Review:The Practice of Programming
This book is written by some heavyweights in the industry: Brian Kernighan and Rob Pike. I have not read previous efforts such as The UNIX Programming Environment or The C Programming Language, but I understand that they are excellent works. I was hoping that this book would live up to that pedigree.
I was not disappointed. The Practice of Programming is a great resource. I found the book to be a good mix of Steve McConnell's Code Complete, Steve Macguire's Writing Solid Code, and Jon Bentley's Programming Pearls: all excellent works in my experience.
Structure
The book offers nine solid chapters devoted to the practice of programming: the tasks that we perform every day to develop software. They range from the beginning of the process (eg, interface design) to the end (eg, testing); from higher-level considerations (eg, portability) to lower-level (eg, naming).
The authors provide examples culled from their real-world experience. I particularly enjoyed their debugging anecdotes, especially their hubris in discussing their own bugs. The authors also provide illustrative exercises, annotated supplementary reading, and an appendix of collected rules. The quality of these is high.
Style
Kernighan and Pike write with facility, clarity, and authority. It is easy to tell that their advice comes from wisdom and experience. I found the text to be readable and enjoyable, and the examples to be relevant and understandable.
The authors' presentation really makes this book valuable. It is neither dry nor difficult to read. In fact, even when they cover difficult material, they are careful to present it in an accessible manner. A college-level programmer should be able to absorb chapter 9, even though the authors build a toy VM with JIT compiler -- not a trivial undertaking.
Examples
The examples in this book really stand out. There are many, almost one per page. The bad examples are appropriately marked with '?' characters, the good examples are nicely commented, and each is concise and typically adapted from real code.
The authors employ many programming languages to illustrate their points. Although they have a distinct bias towards C and Awk, they also present C++, Java, and Perl code, and are careful to use idioms particular to each language.
Often, they will present several versions of the same program. When they do so, they discuss code length, clarity, and related issues, and compare performance, scrupulously noting the environments used.
For example, in chapter 3 they design a single program and implement it in C, Java, C++, Awk, and Perl. In chapter 6, they apply their testing tips to those programs. I appreciate this kind of continuity in a book.
Nitpickings
I have a few nitpicky comments regarding this book. I really don't like the
authors' predilection for short local names, which seem clear in a book's
example but aren't so sensible when being maintained in real-world code. The
world would have been a better place with a compare_strings
function instead of strcmp.
Scott Meyers counsels us (More Effective C++ Item 6) to prefer
preincrement to postincrement, yet the authors continue to use the latter in
loop control statements. The authors also eschew Java's
boolean/false/true in favour of int/0/1; for what
reason, I am not sure.
Still, these are nitpickings. Those issues are relatively minor, somewhat religious, and do not detract from the value of the book.
Summary
I think this is a good book, and I definitely recommend this sort of reading for colleagues of mine. If you've read the books I listed in the overview, then you can get by without this one. However, I feel that it doesn't hurt to be exposed to slightly different presentations of the same material, if only to reinforce the lessons learned.
While I read this book, I was engaged in a coding standards effort in my previous employment. I did find this book, in conjunction with others, to be a useful resource. In particular, I believe it is the most directly applicable book of its sort to development shops that have a lot of C code. That includes the Linux community.
The Practice of Programming is most suited to an intermediate level programmer, although beginning and advanced programmers will also find knowledge in its pages appropriate to their level.
The book's official site contains source code and other resources.
To purchase this book, head over to Amazon and help Slashdot out.
TABLE OF CONTENTS
Preface
Chapter 1: Style
Chapter 2: Algorithms and Data Structures
Chapter 3: Design and Implementation
Chapter 4:
Interfaces
Chapter 5: Debugging
Chapter 6: Testing
Chapter 7:
Performance
Chapter 8: Portability
Chapter 9: Notation
Epilogue
Appendix: Collected Rules
Index
From reading the other comments here, it seems that several readers agree that this book isn't truly necessary if you've already "been around the block", so to speak. That may be true.
However, I am still seriously considering getting this book so that when people ask me "what's a good book on programming", I can reach over to my shelf and grab a good book before they accidentally pick up the latest boat-anchor by some dubious author such as Herbert Schildt* or the like. All too often, people buy books based on size or weight, and not on the solidity of the content. (Even K&R2's latest reprinting is twice as thick as the one I bought, but with the same number of pages.)
If you're a good, professional coder in any reasonable organization, you will eventually be asked to mentor, tutor, or otherwise assist less-experienced programmers. Make sure you can make the best of the opportunity by having appropriate resources ready.
(*Note: I realize that my comments regarding Schildt might be slightly inflammatory to some, but they're not without some forethought. See the comp.lang.c FAQ for more information. And no, I don't let the FAQs think for me -- I've actually seen Schildt's work and found it atrocious. I reference the FAQ since it points out most of the same things I would and more.)
--Joe--
Program Intellivision!
I found this book to be useful, but if you're a halfway experienced programmer, I think you will have dealt with all of these issues and settled on solutions that you are satisfied with.
Everyone has an opinion on variable names, but once you've made up your mind, do you really care how someone else deals with them? Would any advice make you change? This is the sort of thing I am talking about.
This is a good book for someone to look at after completing a few undergrad courses (when they only know enough to be dangerous, and could use the "realignment").
For more experienced programmers, I don't see too much of use.
Just when I'm having fun reading constructive discussion in here, I come across crap like
I would suggest you stop pretending to be an "experienced" programmer and go back and read the book.
Oh Chad, you don't know how many times (a day, perhaps) you benefit from my programming. How droll. And no, I won't tell you what it is or who I am, but if you use a web browser you'll catch the hint.