20th Anniversary 2nd Edition
When I set out to write the first edition of Writing Solid Code twenty years ago, I had a simple thought in mind: Give programmers proven tools, techniques, and philosophies to help them write rock-solid, bug-free code.
At that time, I thought the book would reach a tiny niche market: Very experienced project leads who were running large teams of programmers. I had no idea that the book would become a runaway best-seller, eventually being translated into more than 16 different languages. I certainly didn’t expect that so many software development companies would make the book required reading for their developers. Nor did I anticipate that Universities around the world would use the book in their computer science courses.
Over the years, programmers have regularly asked me if my views have changed much since the book’s original publication.
Not only have my views not changed over all those years, but I’ve embraced the concepts and philosophies expressed in the book’s pages even more staunchly.
The reason for my enthusiasm comes from the many readers who’ve written me telling me how much they’ve benefited by practicing the philosophies that I outlined all those years ago.
I especially value the comments I’ve received from seasoned programmers who’ve been writing commercial code for decades—they, in particular, have the experience to judge whether the book’s suggestions and guidelines make sense in the “real world.”
That’s not to say that these seasoned programmers haven’t sometimes expressed concern about a point here or there. To give one example, in Chapter 2, I promote the philosophy of using program assertions to alert programmers to situations that should never occur in a bug-free program.
Some seasoned programmers have read that suggestion to mean that I propose that you should use program assertions for error-handling and they rightfully disagree with that use of program assertions. An aside on page 22 of the first edition explicitly covers this point, but covering this important distinction just once in an aside clearly wasn’t enough. In this 20th Anniversary 2nd Edition, I revisit this distinction at every opportunity because I so strongly believe in using assertions to help you write rock-solid, bug-free code.
Many readers have given additional insights on the philosophies presented in the first edition, and I’m thrilled to be able to add their thoughts to what has already been presented.
Other readers have written, “Why didn’t you cover this topic, or that topic? These topics are critical to writing bug-free code.”
So true… You could literally write dozens of books on the topic of writing bug-free code. You could write an entire book on the importance of doing code reviews, and how to do them effectively. You could write another book on the importance of creating unit tests and regression tests and how to create and build those effectively. You could write yet a third book on the importance of up-front design before you launch into writing code. I could go on, but I think you get the point. There are so many different angles that you could pursue to writing rock-solid, bug-free code.
When I set out to write the first edition of this book in 1992, I created a list of guidelines to determine whether or not to include a topic or guideline in the book.
I wanted the book to focus on concepts and philosophies about developing code that weren’t widely known, weren’t widely practiced, and weren’t widely written about.
And although I knew I was going to demonstrate the principles using the C programming language, I didn’t want the guidelines to be unique to the C language.
The philosophies I wanted to present, I felt, should be language-independent. With that in mind, I taped a list of guidelines for Writing Solid Code to the wall next to my computer to remind me of these goals.
It’s been 20 years now, so I don’t remember all of the guidelines, but I’ll give you a sampling of guidelines that I do remember…
