Ideally, I would like to give this book a better rating because it is written by a professional. So many of the currently available books on game programming are written by high-school kids who have goofed with the DirectX samples and think they can write a game. Their "hey, dude!" language gets really annoying (yeah, I'm talking to you LaMothe) and the sheer ignorance of their programming style usually makes their books useless.
Unfortunately Mr. McShaffry fell into the same pitfall most other "here's THE right way to write code" authors fall into: he just has too many opinions and not enough facts. He touches on a lot of subjects which are programming religions, and there is no objective right or wrong for much of what he discusses. I feel some of the problem lies in the fact that McShaffry has worked on two types of games: the Ultima series and a playing card game. If you work on one codebase for years, you're going to think your solutions are perfect. As a person who has worked on numerous different types of games and engines I can tell you that there is no magic solution for writing the perfect engine. The engine is always very heavily tailored to the game desired. This is why you hear about the Quake engine, or some other third-party technology, being licensed and then gutted with major portions rewritten. So most of McShaffry's game-specific ideas need to be taken with a grain of salt. An example: smart pointers sure are safe, but if you're working on the PS2 you probably can't spare the memory or execution time for all that tracking.
I also disagree with his opening statements about variable and function naming. This is a constant headache for development teams, particularly game dev teams whose programmers are mostly self-taught. But just saying "Hungarian is useless!" is ridiculous. Sure Visual Studio tells you the type of variable, but this works maybe half the time (it is incredibly easy to confuse Microsoft's Intellitype), and not everyone uses VS. If a person is more comfortable in Emacs, should they be forced to change editors just to get context information on a variable? Is one to three letters of information in front of a variable name really that hard to type?
Those are just a couple of examples for the sake of brevity. My main objection about this book is that I don't feel I learned anything by reading it. I just read Mr. McShaffry's opinions about a few things, some of which had merit, but most of which weren't supported by any factual or reasonable data. They are just opinions. I did agree with his statement that all objects should have a stream-constructor defined; having tried to graft in "save anywhere" to two engines I can attest to the usefulness of this type of planning ahead. But other than that the book is mostly useless to me.
People new to the industry or curious about it might find it exciting to read tales from the trenches. And if you're a pro, I would expect your enthusiasm for the book to be directly relative to how closely your opinions match Mr. McShaffry's. But frankly I wouldn't recommend most of his ideas over anyone else's. Maybe it's the title that grates on me - perhaps a better title would have been "Game Coding: One Man's Opinion"