• The Book
• 20th Anniversary 2nd Edition
• About the Author
• Contact

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…

Don’t include topics that have already been covered thoroughly elsewhere, many times. No rehashing. Stick to little-known concepts.

For inclusion, a guideline must be useable that day, in your current project, immediately after reading the guideline. Don’t include any guidelines that are only valuable if you are designing your project from scratch, before any code is written. That’s a different book.

The concept or philosophy should cause experienced programmers to think, “Wow. I never thought about it that way…”

Don’t include any guidelines that only make sense to C programmers. (Keep in mind, this is not a book about programming in C. It is a book of concepts and philosophies that programmers can follow to write rock-solid, bug-free code, regardless of the language they use.)

Stick to real-world examples that you’ve personally witnessed in projects, on multiple occasions. Don’t use contrived examples simply to make a point.

Share stories of your own failures…

I had a long list of guidelines taped to my wall, but as I wrote, I kept reminding myself that the concepts and philosophies in the book had to be something not well-known and not well-documented already; the readers had to be able to immediately use any concept presented in the book; the concept or philosophy had to make seasoned veterans think twice about commonly accepted practices that they regularly use; and the concept or philosophy had to be largely language independent.

Yes, I occasionally violated some of these guidelines. But that’s what guidelines are. Guidelines. Not rules. Guidelines simply help you keep your focus on what you’re trying to do, or to communicate.

For this 20th Anniversary 2nd Edition, I briefly considered updating the code examples to use a more hip language such as C#, Java, or any of the popular web-based languages that have flourished. The reality though is that the C language is the lingua franca for professional programmers. They may not code in C on a regular basis, but every computer science student has—or should have—learned C in their course of studies. As of this second edition of Writing Solid Code in 2013, C is still the most widely understood programming language by professional programmers and that continues to make it the best language for introducing new concepts and ideas.

If you’re programming in a language other than C, take the philosophies in this book and adapt them to your particular programming language.

Enjoy this second edition of Writing Solid Code!

Writing Solid Code is available in both electronic and print-on-demand formats at Amazon.com.