About the C++ Style in This Book

While I have extensive experience on C++ systems of all sizes, ranging from small to extremely large, I don’t consider myself a language expert. I’ve read the important books by Meyers and Sutter, plus a few more. I know how to make C++ work for me and how to make the resulting code expressive and maintainable. I’m aware of most of the esoteric corners of the language but purposefully avoid solutions requiring them. My definition for clever in the context of this book is “difficult to maintain.” I’ll steer you in a better direction.

My C++ style is very object-oriented (no doubt because of a lot of programming in Smalltalk, Java, and C#). I prefer that most code ends up scoped to a class. Most of the examples in this book fall in line with this style. For example, the Soundex code from the first example (see Chapter 2, ​Test-Driven Development: A First Example​) gets built as a class, but it doesn’t need to be. I like it that way, but if it wads yer underwear, do it your way.

TDD can provide value regardless of your C++ style, so don’t let my style turn you off to its potential. However, a heavier OO emphasis makes introducing test doubles (see Chapter 5, ​Test Doubles​) easier when you must break problematic dependencies. If you immerse yourself in TDD, you’ll likely find that your style shifts more in this direction over time. It’s not a bad thing!

I’m a little lazy. Given the relatively small scope of the examples, I chose to minimize the use of namespaces, though I would certainly incorporate them on any real production code effort.

I also prefer to keep my code as streamlined as possible and thus avoid what I sometimes view as visual clutter. In most implementation files, you’ll find using namespace std; for this reason, although many consider that bad form. (Keeping your classes and functions small and focused makes this and other guidelines such as “All functions should have only one return” less useful.) No worries; TDD won’t prevent you from sticking to your own standards, and neither will I.

A final word on C++: it’s a big language. I’m certain there are better ways to code some of the examples in the book, and I would bet that there are library constructs I’m not taking advantage of. The beauty of TDD is that you’ll be able to rework an implementation a dozen different ways without fear of breaking something. Regardless, please send me your suggestions for improvement, but only if you’re willing to test-drive them!