The Practice of Programming
by Brian W. Kernighan (BrianKernighan
) and RobPike
. ISBN 0-201-61586-X
This book is probably destined to become a classic. It starts out by talking about coding style, then moves on to the importance of algorithms and data structures, program design, interfaces, debugging, testing, performance, and portability. It is very clear writing on an important topic.
You'll find ideas similar to XP in this book. Three principles figure prominently on the cover of the book: Simplicity, Clarity, Generality. This and the name of Brian Kernighan made me buy the book today.
This book strengthens my belief that XP is a collection of practices that expert programmers have been using for years. The academics in their ivory towers, heaping needless complexity on their idle speculation based on subjective observation of anecdotal evidence, are simply wrong. Dangerously wrong.
(Hiding in a corner of an ivory tower)
It's easy to get caught up with the sheer possibility of abstraction and forget how much work it takes to turn the abstractions into working code. One academic I know rates development as "easy". That's a bad attitude because development isn't something we do to prove that we're smart. How would you teach software development as a trade? Lawyers in the English legal system have to do a year of (sometimes unpaid) apprenticeship to become professionally qualified. So should we put every developer through a mandatory period of pair programming?
I noticed this triple on the cover too and didn't buy it - or in that case steal it! Is it fair to say two out of three versus XP? Generality is a very dangerous word in the minds of most programmers. Do they talk about generality in a way that protects against the dangers? I didn't even want to try.
But where when you most need them are the old XpThoughtPolice?
. -- RichardDrake
From my poking through the book, I think 'generality' refers to internal robustness, i.e. not breaking on edge cases and other strange inputs. I don't remember it to have the connotation of building large abstractions.
It's in a similar space to CodeComplete
, though it's not redundant.
I'm reading it right now, and am amazed by the sheer ingeniousness of some of the algorithms, and the practical applications of it all.
I found the book for beginners. Do we really have to learn coding-style HashTable
don't have to read this book.
Depends on the experienced hacker. I'd argue that its worth even the most experienced practitioner occasionally revisiting the fundamentals of their craft. And experience doesn't necessarily correlate with skill or knowledge.
Just recently I came across a bunch of hairy pointer arithmetic to maintain the relationships between the contents of two arrays. Turns out that these two arrays had key-value semantics. "Why not use a hashtable?" I asked. "I thought hastables were just an optimization for when you had too many elements to search through" was his reasoning.