Here are the positive aspects you find:

1. Tries to cover possible issues that could effect coding practices

2. Tries to give names for the common coding problems

3. Tries to explain what is meant my quality of the code

4. Tries to explain logistics behind choosing one coding practice against another

5. Could definitely make a novice programmer a better programmer

Here are the things I don't like:

1. Tries to make money by making a big book. This book doesn't need to be this bg

2. Tries to present obsolete data some times to support nothing

3. Unrelated (to the title of the book) some times meaning less sidebars

From the number of people giving 5 stars to this book, anyone can tell this book is a gem. Most computer science textbooks in university are not doing the software industry a favour. They should use this book instead.

"In dubio, pro reo" - normally, I would give the book two or even three stars. But given the hype and over-enthusiastic voices surrounding it, I was _very_ disappointed after the lecture, and felt responsible to give it only one star as a countermeasure against this whoopla. Why?

In short: "Code Complete" could give a nice, throughout overview of nearly every aspect of software engineering. But it is bloated with quotes over quotes of studies and goes too often into too much details but without really giving true background information.

If you read "Code Complete" with a keen eye, you will notice that there is virtual no first-hands experience of McConnell in it - only the mentioned quotes of studies. And it shows - it gives the naive reader the false sense of knowledge, but will leave him without a true grasp of the material.

Two examples which illustrate the systematic problems in some parts of this book: At one point a study of Xerox from 1964 is used to illustrate how much time programmers spend in meetings, how much time with coding, how much time testing, documenting and so forth. McConnell himself admits that the figures are old. But airily he states that this doesn't matter, without giving any arguments why these numbers - which are not only from the last century but 45 years old! - matter in a fast-developing business as software engineering today! At some other point, he cites "Peopleware" from DeMarco: The best programmers are 10 times faster than the worst. Sadly, in "Peopleware" are assembler programmers compared with higher language programmers... and these numbers are from 1975.

In the chapter about testing he states that testing cannot prove absence of errors. Some pages later he boasts how he tested the final version of one of his programs for weeks with over 100.000 files until he was content with its quality... so he doesn't heed his own wisdom?! And this is one of the few places in the whole book where he gives first-hand experience...

Too keep this review short, I don't go into detail with the many inaccuracies and rhetorical dodges. They are simply annoying.

From my own experience I have to say: Any software project manager giving this book to experienced programmers will getting compliance, but no commitment. Being blunt: They will scoff at the shallowness of the book, given its size. A more compact treatise would have been way better. So I consider this book a wasted chance - after all this only one star, I'm afraid.

Id write my own full length review but... I cant think of anything else to praise this book about that hasn't already been praised. Its a great book for both the novice and experienced programmer. If your serious about improving your software construction skills, this book is a MUST READ. It should be required reading for all programming degrees since it is pretty much language neutral. The lessons in this book will apply to pretty much any programming language out there at any time.

This is a great book! If you are intrested software design and coding, this book is a MUST! I've leared so many things i didn't know about in college. 100% recommended =)