I've read this book cover to cover and found myself quite annoyed of it most of the time.
Contrary to the stated intended audience, a professional programmer with real industry experience of more than a couple of years will find most of the advice here shallow, boring and obvious.
This book could have easily been cut by 50% without any loss of real content by avoiding repetitions, useless information and self references.
This book is heavily grounded in practices of C++ and Java and contains almost nothing for programmers of other languages like Python, Perl, Ruby, Javascript, lisp, PHP etc'. It contains no word about the functional programming paradigm and acts as if OOP is the only way to go. This goes to an extreme in a hilariously absurd section about recursion which states that "Recursion isn't useful often" and that it should be considered only for "a small set of problems".
The best programming advice I have ever received and which I pass along to the author is to learn another language. Preferably one that is widely different from what you're used to.
A few other annoyances I found throughout the book:
- The template "A study performed at [COMPANY X] in [19XX] found that [SUPPORT CURRENT CLAIM]". These kind of statements are meaningless to me as a reader. I don't care who did the study and when it was. I do care about how that claim was validated and how the method is still relevant in present days. That bit of information is almost always missing.
- The chapter about code tuning contains a lot of number and comparisons of different techniques but lacks any real credibility since it fails to state the conditions in which the techniques were tested. Some of the things described are highly processor and compiler dependent. Some depend heavily of the amount of cache and memory and the data being used. The author does excuse himself by saying that before you do any tuning you must first profile and look for hot-spots but that doesn't excuse him from basic scientific method and academic decency.
- Almost every chapter starts with something like "If you're not interested in Y and are interested in X you can skip to section Z". This is what the index is for.
- All of the side bar notes titled "cross reference" and "further reading" are superfluous. It almost seems like the author did a text search to find where the current subject is also mentioned in the book and linked there. Again, this is what the index is for.
- Repetition. some of the advice and anecdotes appear again and again and again. By the end of the book it felt like I've read the sentence "Use boolean functions to clarify boolean tests" atleast a dozen times. Another extreme example was a section of about 4 pages with some 20 bullets on some subject which is followed by a page and a half "check list" section which contains a summary of those 20 bullets.
- Contrived examples. When the author wants to make the point that something is bad you can be sure that he'll come up with the most stupidly contrived example to make that point. A more interesting approach would be to look at something that an actual, non-brain-dead, programmer would actually consider writing, explore the reasons why he would write that and explain what is wrong with his reasoning.
If you're a professional not just fresh out of CS studies and you keep yourself informed on blogs like "Joel on software" and "Coding horror" (which borrows its logo from this book) you can safely skip this one.
Get more detail about Code Complete: A Practical Handbook of Software Construction.
No comments:
Post a Comment