From the Preface

Welcome to The Rules of Programming, a set of easy-to-remember and easy-to-apply Rules that will help you write better code. Programming is hard, but following the Rules makes it a little bit easier.

Here are some tips on reading the book:

• All of the Rules stand on their own. If you see an interesting-looking Rule in the table of contents and want to jump straight into the middle of the book, feel free. That reading pattern is fully supported.
• That said, I’d suggest starting off with Rule 1, “As Simple as Possible, but No Simpler”. It’s a good setup for the rest of the Rules.
• The examples in the book are all written in C++. If you’re a Python or JavaScript programmer, you’ll be happier if you read Appendix A, “Reading C++ for Python Programmers”, or Appendix B, “Reading C++ for JavaScript Programmers”, before getting too far into the Rules. The two appendices act as Rosetta Stones to translate that C++ into the concepts you’re used to. If your experience is with some other language and you find the C++ examples hard to follow, then I suggest the phenomenal website Rosetta Code.
• If you’re a C++ programmer, note that I’ve simplified a few things in the code examples to make them easier to read for non-C++ programmers. For example, the examples use signed integers in a few places where unsigned integers would be more typical for a C++ program, and I disabled warnings about implicit conversion between signed and unsigned values. I also compiled the examples with an implicit “using std” to avoid a boatload of distracting “std::” references.
• And finally, I’m capitalizing Rule when I refer to an actual Rule in the book. If you see rule, it’s just a regular old rule, not an officially sanctioned one. The distinction between the two senses of the word was confusing without the capitalization; I hope that excuses me.

I hope you enjoy what follows! I think you’ll discover a few useful thoughts that help you sharpen your programming skills.

A big part of the recruiting strategy at both Microsoft and Sucker Punch has been hiring smart young programmers, then training them in the ways of professional developers. This practice has been undeniably successful, but it also leads to a particular flavor of frustration.

I kept running into one problem over and over again. We’d bring a new programmer onto the team, often someone fresh out of college. I’d review some new feature they planned to introduce into the code, usually to solve a very simple problem—only to discover that they’d written code that attempted to solve a much bigger problem, one that included the very simple and concrete problem as a small subcase.

Aargh! We didn’t need that bigger problem solved, certainly not right now! Invariably, the solution to the bigger problem was a mediocre solution to the simple problem we did have—more complicated to use, more complicated to understand, and capable of hiding a lot more bugs. But just saying that in the code review—that we didn’t need the bigger problem solved, that they should only try to solve problems they understand—was ineffective. They kept doing it.

Out of frustration, I put my foot down. “OK,” I said. “Here’s the new rule. Until you have three examples of a problem, you’re not allowed to write a general solution.”

To my surprise and delight, this actually worked! Turning the general philosophy into a specific rule with specific criteria was an effective way of getting the message across. Sure, most of our new programmers made the premature generalization mistake once, but the rule helped them avoid making it again. It also helped them recognize when it was time to generalize. Fewer than three examples? Don’t generalize. Three or more? Start looking for opportunities.

The rule worked because it was easy to remember, and the situations where it applied were easy to recognize. When coders could see that they had started moving past the bounds of the well-defined problem at hand, they could take a step back, count the number of concrete examples of that sort of problem they’d run into, and make a better decision about whether to generalize or not. They wrote better code.

...

So, bit by bit, what was once a single rule grew into a list of rules: the Rules of Programming described in this book. They represent many of the most important aspects of Sucker Punch engineering culture: the things that we believe have led to our success, the ideas that new coders on the team need to absorb to be effective. The things that even senior coders like me need reminding of at least once in a while!

Each of the chapters that follows describes a Rule, with plenty of examples to illustrate the thought behind it. After reading a chapter, you should have a clear idea of the coding practice the Rule encourages and the situations where it applies.