Top critical review
65 people found this helpful
on February 17, 2010
I am extremely sad for what I am about to say, but unfortunately this book has lost most if not all of its relevance over the last 15 years. I don't think today is a very useful book to read anymore.
I read a few books on and around C++ (say the 4 Sutter's, the 2 Alexandrescu's, the 3 Meyers, many parts of Knuth's Art of Computer Programming, Kernighan and Pike, Refactoring, Design Patterns, Analysis Patterns) and maybe about a half of this book. A this point I stopped. Note that this is well into the physical design part, which was the reason I bought this book in the first place. I am extremely disappointed with the book, enough that this is probably the first time I don't finish a programming book.
There are two principal bad points about this book: one is the density is way too low, the book is about 600 pages, the same stuff should have been edited down to maybe 250 (one could say this is the editor's job, btw, but still it's our time which is not made best use of). The other one is that most of what the author talks about are either suggestions for protocols that nobody would use today (take the proposed iterator interface: since the STL became standard, nobody iterates like Lakos suggests anymore) or, worse, based on circumstantial evidence of the system the author was using at that time: a lot of the book is concerned with reducing inclusion dependencies which in the text is mostly supported by a measurement the author made on his system, and then marginally by the necessity of being able to undergo low costs when moving files around a project for reuse (which instead, on its own, is a pretty good point: if there's too many complex inclusion dependencies, relocating a file for refactoring, or pulling it into a different project can become a nightmare).
Unfortunately he took a seriously wrong choice to attack his problem: he chose to manually solve the problem with various tricks and hacks such as external include guards, instead of building himself a simple tool like a pre-preprocessor or something of the kind. Needless to say, for the case in point, modern compilers have no need for such guards, as single inclusion is built into all the (current) tool chains I know *OF* (let alone the ones I use!) (this is necessary for building big systems, because headers could reside on a network, and it would be unwise to pull the same file across multiple times, once you have the file across, you parse it once, and then use it as necessary). So yes, he deserves the credit for identifying a problem (assuming he's been the first to describe it), but most certainly not much credit for the solutions proposed.
While reading, I have spent copious amounts of energy trying to salvage in my mind the most from what the author suggests, but I gave up, under the impression that the update work needed was quite more than the information that could be kept unchanged.
At this point I went back, and reread all the reviews on Amazon and figured that the part I read was actually the "good" one, while the section on logic design was even more out of date, and this is where I stopped reading.
Summing up, the one good point of the book is outlining that headers can be thought of as graphs of dependencies, and that keeping these graphs as acyclic as possible solves so many problems that it's for sure well worth including as one of the primary design goals in a project. A few techniques are shown on how to achieve this goal. Some are of some value, none was particularly non-obvious (any simple technique in Sutter, Meyers or Alexandrescu is quite more sophisticated than what's discussed here).
So, any book that pointed out what I said in the phrase above is worth maybe two stars, this author lost one due to his complete inability to summarize and come directly to a point. One extra star was then added in consideration to the person who so warmly recommended this book, as he is a very experienced programmer.
By the way, I realized after the fact that I have also been (in the past) a user of one of the packages from the company the author was working for, as well as a couple of competitor and more or less equivalent packages. I most definitely cannot say that *from the user experience standpoint* the product was any better than the others, actually it seemed quite disrespectful of standard platform conventions for default file storage, for example.
One last word:
I'm not sure this is relevant to all readers, but the style and typography of this book are surprisingly poor. The text is set too big and is poorly spaced, there are too many visual jumps in spacing and density, many pictures are related to text in a non-visible page (typically the previous one) and most pictures are way too big for the little information they represent. For a book that has received this level of credit (and a publisher of otherwise rather beautiful books) I had expected a *much* better look and feel than this.
I think a more modern replacement for this book would be Sutter and Alexandrescu's "C++ Coding Standards", which does not have an explicit part on physical design issues, but gives you enough food for thought to build yourself quite naturally good practices in that domain based on the rest of the discussion. One of their opening points is "don't sweat the small stuff". Great advice.