| Large-Scale C++, Volume I |
|
Author: John Lakos Well it certainly means a large scale book - at over 900 pages I got wrist problems trying to read it. I also have to admit that I didn't read all of it and I doubt many readers will read it cover to cover. I have to also admit that after starting to read it I was struck by a feeling that programming cannot be as difficult as this book suggests. Who, with a reasonable human brain, can possibly absorb this amount of stuff? In a good logical system what you need are a few general rules that you can apply, not 900 pages of detailed tiny design rules - hundreds of them... This is a book of spells and, while most of them are founded in good sense, they fail to make a coherent whole. If good programmers are supposed to memorize, or even attempt to understand. this much detail then they aren't going to have much left over for anything else. What is also important is to know that these rules are not general in the sense that they are about design in a language free context. They are about C++ and some of its strange gotchas. Some architecture books make you feel better about your language of choice. This one started to make me think that C++ was not a language any sane programmer would choose. In this I now share the opinion of Linus Torvalds: “C++ is a terrible language”. 
The first chapter digs into compilers and linkers and is much easier to understand if you already have a clear idea of what they do and what the compromises are. Some of the examples are fun, but most are obvious as soon as you think about what is going on - declarations and definitions not being resolved until link time. My feeling was "so what, as long as the problem is spotted at some point and there's no harm done" and my second feeling was that most of things listed should happen automatically if the project is reasonably well documented. The second chapter mixes ideas of packaging with design rules. It gets into some very tiny fiddly details, like when you should use underscores in names and when camel case. Personally I don't think any of these idea solve the naming problem. There are a lot of diagrams of supposedly huge program structures - if you have a program this big its probably far too late to go back and make things simple. Chapter 3 brings the book to a close - yes, just three chapters. It is about physical design and refactoring and it basically comes down to avoid cyclic dependencies and use lateral structures rather than layered. Conclusion: There were large tracts of this book I found interesting, but I have to admit that I kept trying to see a bigger picture and one didn't seem to be forthcoming. It was either very much micro-managing things or switching to huge overviews that were difficult to pin down. This isn't so much a philosophy of architecture as a rule book with justifications. It was also repetitive of basic principles - yes cyclic dependencies are bad. If the book was about 200 pages then perhaps it would work better As it is there is volume II and III to contemplate.
To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.
|
|||
| Last Updated ( Tuesday, 04 May 2021 ) |