Another book not to repeat mistakes that already made millions of times by other developers. Steve McConnell shares his and lots of other books’ authors’ experience in book Code Complete.
Some Outdated practices
Book initially published in 1993 and renewed in 2004. Maybe therefore it gives us arguable advices. For example, author wrote that it is better to add m_ prefix member variables. How I know this practice is not widely used. Also in chapter about performance he wrote:
In the first edition, I ran most of the tests in this chapter 10,000 to 50,000 times to get meaningful, measurable results. For this edition I had to run most tests 1 million to 100 million times.
Steve wrote that if performance is the priority order, we need to care about compilers. For example, sometimes it is better to write:
if (A && B)
because in last case some compilers check the second condition even if first is false. I thought it is obvious that compiler should stop checking conditions as soon as possible, but I will pay attention about such details. Anyway nowadays in most cases readability have priority over little improvement of performance.
Lots of statistical data
There are lots of comparisons using statistical numbers. In most cases we just say it is better to write tests than to not write. In this book Steve will prove it using numbers. For example, let’s have a look at table from the book.
|Project Size (in Lines of Code)||Typical Error Density|
|Smaller than 2K||0–25 errors per thousand lines of code (KLOC)|
|2K–16K||0–40 errors per KLOC|
|16K–64K||0.5–50 errors per KLOC|
|64K–512K||2–70 errors per KLOC|
|512K or more||4–100 errors per KLOC|
There are dozens of such interesting tables, graphs.
Short explanations – it is not about this book
This book pushes me to learn little bit about speed-reading. There are almost 900 pages of content. In my opinion, most of topics can be shortened. But formatting is pretty good, so reader can skip some paragraphs after reading first sentence, where key point is written.
Surely almost everybody will find something interesting and new in this book. For me 21 chapter (Collaborative Construction) and 22 chapter (Developer Testing) were most interesting.
This book covers not only coding problems, but also some designing and management problems. So some chapters would be very helpful for software team’s managers.
During reading this book I copy-pasted interesting paragraphs to publish here as citations, but then recognized in that case most of post would consist of citations. I assume I will return to this book every time need to make architectural decisions.