Code Complete: A Practical Handbook of Software Construction, Second Edition 2nd Edition
Use the Amazon App to scan ISBNs and compare prices.
- List Price: $54.99
"Devoted" by Dean Koontz
For the first time in paperback, from Dean Koontz, the master of suspense, comes an epic thriller about a terrifying killer and the singular compassion it will take to defeat him. | Learn more
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Frequently bought together
About the Author
Steve McConnell is recognized as one of the premier authors and voices in the development community. He is Chief Software Engineer of Construx Software and was the lead developer of Construx Estimate and of SPC Estimate Professional, winner of Software Development magazine's Productivity Award. He is the author of several books, including Code Complete and Rapid Development, both honored with Software Development magazine's Jolt Award.
- Item Weight : 3.35 pounds
- Paperback : 960 pages
- ISBN-10 : 0735619670
- ISBN-13 : 978-0735619678
- Product Dimensions : 7.5 x 1.63 x 9.13 inches
- Publisher : Microsoft Press; 2nd Edition (July 7, 2004)
- Language: : English
- Best Sellers Rank: #21,287 in Books (See Top 100 in Books)
- Customer Reviews:
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
Comprehensive Analysis of Software Construction
This book’s scope is the “construction” of software which primarily includes detailed design, coding, debugging, integration and developer testing. According to McConnell, there wasn’t a book written on the construction aspect of programming at the time of writing the first volume (in 1993). Also, according to McConnell, construction is the most important part of programming as it takes up the most time, it must be done, and it has the biggest impact on the success of a project. To sum it up, this book touches on everything you need to know during the construction phase and has a chapter devoted to each topic. My favorite chapters are Chapter 6 (Working Classes), Chapter 21 (Collaborative Construction) and Chapter 33 (Personal Character). Go look at the table of contents if you don’t believe this book is comprehensive.
Objective and Scientific
McConnell backs up most of his claims with scientific evidence (referencing the results of different programming studies) throughout the book. He is also objective and presents dissenting opinions when there isn’t a clear winner. He is also honest when there isn’t much evidence to support his claims (for example, there isn’t actually much evidence backing up his documentation techniques even though they are probably best practice). This builds trust between the reader and the author. We know he has done his due diligence and we don’t need to go fact check everything. His technique of backing up opinions with scientific studies is surprisingly lacking in most software communities. It makes me realize how often we spout opinions without backing them up with hard data.
Well-written and Well-organized
This book might be dry at times, but it’s very well-written and well-organized. You can skip around to different sections and use it more like a reference instead of reading cover-to-cover if you’d like. My favorite parts of its organization are the ‘Key Points’ highlighted throughout the text, the checklists and key points at the end of chapters, and helpful code examples which reinforce his points. Also, I love his metaphor that you should organize your code in a similar logical structure that you would organize a book (with table of contents, sections, chapters, etc.) Some will say the book is repetitive (and it can be), but repetition is important because you rarely remember anything after reading it once. Repetition is the way ideas are reinforced and remembered.
Carries a Lot of Weight in the Industry
Some might argue this shouldn’t be a factor when reviewing a book, but I disagree. When you are newer to the industry (I’ve been programming professionally for around 2 years), you need to learn from the best. The way you identify who is best is by someone’s reputation and status in an industry. This book (and McConnell himself) are held in high esteem by very influential people in the industry. This matters because you can trust the concepts he is advocating and move quicker in your learning.
Overall, this book is a must-read for programmers and will probably have the best ROI for programmers who have been working professionally for 1-2 years (because you’ve seen some of the good and some of the bad practices that McConnell talks about). Yes, this book is long, sometimes dry and repetitive, and some advice is obvious. But it absolutely helps give more confidence when constructing software, when giving code reviews, and when forming a culture of good habits on your team.
The main takeaway is this: your number one goal as a programmer is to manage complexity. Make things easier to understand, more readable and more maintainable - it will save time in the long-run. We spend much more time reading code than writing code. It’s important to think about the programmer who will be reading and maintaining your code (a lot of times it is yourself). We aren’t smart enough to understand entire codebases and we are limited by our brains. Use techniques like abstraction, encapsulation, self-documenting code, and collaboration with other programmers to make your code better.
It’s a dense book, but all is worthwhile information for the developer who is just getting started in the industry. The material spans across all areas of “software construction” — that is, the process of implementation of the software project itself. Areas are not limited to the following: writing high quality methods/functions, variable naming, how to write clear loops, refactoring, debugging and being practical on trade-offs of performance and style (a short debate on GOTO is talked about here) during implementation.
There is a lot of material, and I won’t really spoil it all here. Just keep in mind that it isn’t a book where you would have to read cover-to-cover. I think it’s best read in pieces. Pick out the topics that interest you the most. For me, it was debugging. The scientific method type of approach to debugging described in this book has been my approach to debugging for years now… It has made me effective in fighting bugs and has made me a better
team member in a software team overall.
For the early-career developer, this is what I would almost consider, required reading.
Now, is this the book to read if you have lots of software development experience? Well, that depends. Ask yourself honestly… do you have 10 years of the same 1 year of experience? Or, do you have 10 years of cumulating experience where year-after-year, you are constantly improving yourself? If you are the former and look to moving onto the latter, then definitely read this book.
Top reviews from other countries
Some of the detailed nuts and bolts advice on construction is sound but in this day and age it seems odd that it needs saying as nobody would consider doing otherwise (would they?). For instance multiple injunctions to consider maybe possibly using source control are hopefully no longer doing useful work on the reader.
The notion that Visual Basic is a credible choice of programming language also seems peculiar now, but I can't remember a time when that wasn't true 😜 You can easily spot sections that are new or revised in the 2nd edition because they are aware that C# exists.
The book still gives a good overview of a range of topics, though many of them are covered better and in more detail in other books like The Pragmatic Programmer, Refactoring (Fowler) and Clean Code (Martin) . I'd like to say that this book is a good introduction and starting point, but without a refresh to bring it more up to date it's not an easy pitch. I'm not sure there's anything that's as comprehensive but more up to date though?
The Golden age of books about the art and craft of software engineering does seem to be behind us... I guess with all the resources available online now there's not enough of a market, but blog posts and video tutorials can never quite replace the insight you get from reading the thoughts of an experienced programmer who's spent time thinking about what they do and how they do it, and on consolidating those thoughts into a doorstop for communication. There is a perspective, a world view, a joined up pattern of ideas presented here that is more than the sum of the occasionally questionable parts, and there's value in that.
This book is worth a read for all of us, at any level. Ok, maybe a beginner wouldn't get it, but if you've been hacking code long enough to know the modern languages are abstractions and simplifications of what came before then you'll read through the parts that seem less obvious.
Maybe or maybe not a spoiler, but if in doubt, try writing a test case, see how it pans out. Simple and obvious. Most of what is in this book is simple and obvious, but then we do all need that pointing out often and frequently!
It's not a bible of coding, there is no such thing, but it is something we should all have a go at. I didn't rail against anything Steve had to say (unlike, say, Cooper), but that isn't to say he or I are right. I do think he is sticking to making sensible observations about what he thinks is worth saying from a lifetime of coding, as oppose to trying to be exciting. For that alone, I recommend him.
Every company that develops software products should have this in their library: you do have a library of software development books don't you?
This last should be the 13th Joel Test.