The focus of Code Complete is software construction, i.e. the coding part of software development. As Steve McConnell notes in the preface, "construction is the only activity that is guaranteed to be done". You can skip almost any step (requirements, testing etc), but if you don't write any code there is not going to be any software.

I bought my copy of the first edition of Code Complete in 1997, and I was immediately fascinated. I had never read anything like it before - a book that concentrated on the actual writing of the code. For example, it had a whole chapter on if- and case-statements, and another chapter on the naming of variables. I had no idea there was so much to learn about these seemingly straight forward activities. It was immediately useful to me, and I started to apply as much as I could of what I learnt from it.

Although it concentrated on coding, it covered a broad spectrum of activities around coding, from requirements and design to testing, debugging and optimization. It also had a great reference section with suggestions of further reading in the area of software engineering. This became my starting point for finding lots of other good books to read, like Peopleware: Productive Projects and Teams (Second Edition) and Programming Pearls (2nd Edition).

So this summer I decided to re-read this seminal book, partly to see what's new in the second edition, and partly to see if still think it is such a great book.

To answer my own question - yes, it is still the number one book on writing code. It is near encyclopaedic in its coverage of the nuts and bolts of programming. There are chapters on the naming of variables, on organizing straight-line code, on conditionals, on loops, on lay-out, on good commenting and on how to write good methods.

In it, there are frequent references to scientific studies that support the advice given in the book. For example, how long should variable names be? Instead of just giving us his opinion, McConnell summarized the findings of several scientific studies on the subject.

Each time there is reference to a study, there is a little "hard data" symbol in the margin. There are other symbols in the margin as well, "Coding Horror" for code examples of what not to do, and "Key Point" for, well, key points. The margin is also used for cross references to other chapters, and for quotes related to the subject discussed. For me, this works really well. It is both useful and makes the text easier to read. In general, the book is very well laid out.

Some of my favourite advice from the book (all of which I remember from reading the first edition) are:

Chapter 7.1 Valid Reasons to Create a Routine - for example: Reduce complexity, Introduce an intermediate understandable abstraction, and Avoid duplicate code (there are 6 more valid reasons in this chapter). The second part of the chapter is called Operations That Seem Too Simple to Put Into Routines and contains a great example of why it can be good to put even a one-line calculation in a routine - the code becomes more readable, and small operations tend to turn into larger operations.

Page 172 (and 264 for variables) Use opposites precisely. When naming "opposite" methods and variables, be careful to use the correct pairs, like add/remove, begin/end, create/destroy etc. This makes the relationship between them clear and obvious.

Page 433 Break complicated tests into partial tests with new boolean variables. This is such a simple thing, but it makes the code a lot more readable.

Page 754 "Make the incompleteness of a statement obvi". For example, when breaking up a logical and over two lines, end the first line with && - that way, it is clear that the statement continues on the next line.

Even though the book truly is great, there are a few things to complain about. In the first edition, the chapters on layout and comments came right after the chapters on the different control structures. But in the second edition, these two chapters have been moved further back. To me, that doesn't make sense, since they too are related to how you actually write your code. Now there are chapters on testing, debugging, optimization and refactoring in between.

And talking about refactoring: while this is an important subject, I don't feel the chapter on refactoring is particularly good. This chapter is new in the second edition. The summary of refactoring is OK, but a good part of the chapter consists of just listing different kinds of refactorings.

Overall though, the second edition is a nice face lift. The code examples are now mostly in Java, C++ or Visual Basic (in the first edition they were in Pascal, C or Ada). But since all the major themes of the book were already present in the first edition, it does not make a big difference if you happen to read the first edition instead of the second edition.

Code Complete is thick - 862 pages (not counting the bibliography and index). If that feels like a lot to read, then I suggest you start by just reading one or two chapters, for example "Using Conditionals" or "Layout and Style". They (and pretty much any chapter in the book) can easily be read without first reading the preceding chapters, and these will give you a sense of what you can expect from the other chapters. Even if these are all you read, you will still get a lot of value from the book.

However, if you are a programmer and care about how you write code, you owe it to yourself to read the whole book. It is considered by many (including me) to be the best book available on programming, and it will almost certainly make you a better programmer. Highly recommended.

This book deserves 5 stars because it is a comprehensive analysis of software construction, it is objective and scientific, it is well-written and well-organized and it carries a lot of weight in the software industry (yes, this is important).

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.

Conclusion

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.

The tragedy for books that become classics is that there are many more people who have heard of them (or perhaps also bought them) than people who have read them. In this case, the fact that Steve McConnell's "Code Complete" is approximately 900 pages long doesn't help, either. Even so, this is a book that not only deserves to be read, but also rewards multiple readings.

The Good: McConnell deserves credit for writing the first (and only?) readable encyclopedia of best practices on software quality, covering topics such as how to build classes, use data and control structures, debug, refactor, and code-tune. Yes, it would be nice if the book was updated to include substantive material on languages like Ruby or Python (cf. p. 65, Python "also contains some support for creating larger programs") but, in the words of Gertrude Stein, "Not everything can be about everything" -- though Code Complete does come pretty close. This book contains an astonishing number of practical points on a variety of topics. Here is a quasi-random selection: a) don't use booleans as status variables (chs. 5, 12), b) when you feel the need to override a function and have it do nothing, don't; refactor instead (ch. 6), c) when choosing variable names, avoid homonyms (ch. 11), d) if you decide to use a goto, indenting your code properly will be difficult or impossible (ch. 17), e) trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often (ch. 22), f) make your code so good that you don't need comments, and then comment it to make it even better (ch. 32), and finally the oft-repeated g) you should try to program into your language, not in it (ch. 34). McConnell also sprinkles the text with classic words of wisdom, e.g. "The competent programmer is fully aware of the strictly limited size of his own skull" (Edsger Dijkstra), "Never debug standing up" (Gerald Weinberg), "Copy and paste is a design error" (David Parnas), "Any fool can defend his or her mistakes -- and most fools do." (Dale Carnegie). It is important to point out that even though this volume is encyclopedia-like, it does have both a sense of humor (e.g. "the encryption algorithm is so convoluted that it seems like it's been used on itself") and a clear authorial voice (e.g. "Though sometimes tempting, that's dumb."). Another example of the latter: in ch. 33, after quoting Edward Yourdon at length, McConnell adds "This lusty tribute to programming machismo is pure B.S. and an almost certain recipe for failure".

The Bad: overall the writing is very good, but the occasional infelicity reminds us that McConnell is human (e.g. p. 369 "A loop-with-exit loop is a loop in which", p. 809 "A program contains all the routines in a program."). In a technical book of this breadth, minor mistakes are bound to creep in. For example, in ch. 10 McConnell mentions the different possible levels of a variable's scope in C++, and then adds that in Java and C# one can also use namespaces, thus effectively ignoring the existence of the namespace concept in C++ (which is baffling, given that he then discusses precisely that topic in ch. 11). Another example, this one more serious, is McConnell's recommendation that you should use a pointer - not a reference - if you want to pass by reference in C++ (ch. 13), something which is contrary to C++ best practices (see e.g. Sutter & Alexandrescu, "C++ Coding Standards", Item 25). A less technical point: in ch.2 McConnell criticizes Frederick Brooks for writing (in 1975): "Plan to throw one away; you will, anyhow". I found this to be bizarre, given that in the 1995 edition of "The Mythical Man-Month" Brooks states in no uncertain terms that he has changed his mind on this: "This I now perceive to be wrong" (p. 265). Given that Code Complete 2 was published nearly 10 years later (in 2004), criticizing Brooks for his publicly repudiated former opinion seems improper. On a different note, although some of the on-line accompanying material is fascinating (e.g. the links to the original Dijkstra and Lawrence articles in ch. 17) many of the links are just electronic versions of McConnell's checklists or bibliographies, while some are simply disappointing. To name only a couple of these, as of this writing the link on p. 856 on the economics of XP is a dead link, while the one on p. 76 is downright embarrassing (it links to a google search for "emergent design"). Finally, even though the book has a dedicated website, no list of errata is provided there. If you dig deeper, you can find one on the O'Reilly website, but that is woefully inadequate, e.g. it contains no information on separate printings.

The most common criticism one hears about this book is that any decent software developer should already know the material covered in it. Ironically enough, this is true. To quote Dr. Johnson: "People need to be reminded more often than they need to be instructed".

Alex Gezerlis

The most revealing comment in the book is that when Steve McConnell sat down to write it, his initial impression was that it would be approximately 250 pages, yet when he set out to plan it in detail, he realised it would be 800 pages. As a result, the book consists of one third genuinely insightful material. Everything is repeated at least once, adding another third to the length. And there is another third of the book that can be considered "filler" - topics covered very lightly, so that the book will live up to the title "Complete". Specifically, Chapters 1-5, half of chapter 6, and chapters 27-33 could easily have been omitted. The result would have been something of power of Scott Myers Effective C++, a book that is frequently referenced and clearly admired by Steve McConnell. Rather than read these superfluous chapters, the reader would be advised to head straight for the books and articles given as further reading in these sections. As a general rule, pages which contain code are the ones worth reading.

However, I think that the 250 pages of real content is exceptional and all serious programmers should read this book at some point, particularly if self-taught or have never worked on a large project before. The book collects a huge body of programming lore, that is often rediscovered or passed on as superstition between programmers. The focus, always, is on readability and robustness, which are easily forgotten in the rush to code. Overall, the advice in this book is clear, practical and good. A particular highlight is the gathering of research on where time is wasted in coding and how it can be avoided. Inevitably it is most valuable for those relatively new to programming. But even experienced programmers need reminding about many of the ideas every now and then.

I don't agree with everything McConnell suggested. The book is happy to recommend the long parameter lists and verbose variable names typical in Windows and Java programming. There is also a clear bias towards the Microsoft environment and Visual Basic in particular (comprising about a quarter of examples) . The somewhat rigid and overwrought UML style of structuring object-oriented code is advocated over more flexible layered approaches. Nevertheless, I think that there is nothing that is clearly bad, and if followed rigorously would improve the quality of almost any project.

At 800 pages, it is a long read and arduous at times, but in the end well worth it and the best parts are wonderful.

I finally decided to invest the time in reading Code Complete after hearing well-spoken computer scientist Greg Wilson sing its praises on a Ruby Rogues podcast episode. Greg felt this book should be the core textbook in every undergraduate CS program although he will buy you a beer if you can find it in one. Greg says that Steve McConnell has practically memorized every significant industry paper written in the last 30 years. That knowledge shows in this book and its an especially great read for those who want hard data to back up claims.

Even though Code Complete is arguably the most recommended programming book in the industry, I get the sense it is underappreciated by most folks who work in my ecosystem (open source/ruby/linux/etc). Whether that is true or not, here are a few reasons why I think it may be the case:

1.) "It is a Microsoft book and uses Visual Basic in some of the examples." Well, after reading the book cover to cover, I don't feel either of these were a problem. McConnell makes the conscious choice of using multiple programming languages throughout the book under the rationale that a good software craftsman should be comfortable parsing somewhat unfamiliar syntax. He even points out an instance or two where he feels a VB implementation decision is superior to what is found in most programming languages. Don't get me wrong, nobody is saying VB is a great language, but to write off the book because of the connection would be foolish.

2.) "Its a book about things I already know. I found a bullet point summary online and didn't have any 'aha' moments". My response to that is this: While I can't point to any particular section that will be mind blowing for most developers, I found myself transformed into a much better programmer while I was reading this book. Furthermore, in 2012 Sandi Metz released a book that has become an undisputed classic in the Ruby community. It turns out that a lot of the good OO design practices taught in her book appeared in Code Complete many years earlier in language-agnostic form.

3.) "Its almost 900 pages". I admit--the length of the book is a drawback. However, when you examine the contents, it is clear that McConnell is attempting to cover more ground in a single book than anyone before or since. It is also pleasant reading--not light reading by any means, but its not stereotypical textbook reading.

Something I did not know about this book in advance is that it is an excellent gateway book for the software engineering classics. What do I mean by that? Anyone who has done research on widely recommended software books knows that the list of classics is long and intimidating. Code Complete is the only book I've seen that incorporates ideas from dozens of classic works. There is an entire chapter based around Martin Fowler's Refactoring. The Mythical Man Month and The Pragmatic Programmer are quoted throughout. McConnell ends the book with a software developer reading plan that includes him giving a great testimonial for Programming Pearls. There are also references to Effective C++, Peopleware, and Kent Beck's TDD just to name a few more.

Finally, to show I'm not a total fanboy, I'll list a few things that were a little disappointing.

1.) McConnell dismisses functional programming pretty early on in the book. He believes in avoiding recursion unless its going to save you a massive amount of coding. While I wasn't expecting functional programming to be a core value in the book, I think it looks bad 11 years later that it was waved off as inconsequential. And for those who are wondering, no, SICP did not get a shout out.

2.) Going back to the Microsoft connection, I feel as if the words "open source" were tiptoed around. To his credit, McConnell does recommend SourceForge as a place to look at production code that is likely well-written. However, the way it was presented felt as if he was walking through a landmine and trying not to set a suit on fire.

3.) Similarly, the value of Unix tools felt downplayed. The tooling chapter felt it was more appropriate to describe tools anonymously because tools change over time. While there is definitely some truth to that, it felt a bit like a way to justify confining Unix tools to a paragraph.

In summary, I would recommend this book to programmers at any level. Its one heck of an education for around $30 and deserves its reputation as a classic. When you finish, you will feel as if you completed a long apprenticeship with a master.

I don't know how much more I can say about this book that hasn't been said already but I will do my best to describe my experience with this book.

Have you ever looked at a class, or a method that seems to work fine but it just doesn't "feel" right? For some reason it seems as if that method or class may be hard to debug in the future or that the code is hard to understand. Or have you gone back to a class file you wrote months ago and you spend an awful lot of time trying to figure out what the heck is going on with that class file? Maybe the methods in the class are spaghetti like in nature, or maybe the names of your methods don't have a very good description so it's hard to figure out how everything ties together. I have had this problem. This book will teach you how to get out of those habits. You will learn what a solid class or method looks like. You will learn how properly naming your classes and methods can greatly reduce complexity in the long run. Everything is backed by hard evidence. I should also mention that this is just one chapter in this wonderful book.

This book really drills down proper programming practices. A lot of times you may read a passage and think to yourself "well, of course!"... but then you realize you don't practice what's contained in the passage you just read. This book is great for both new programmers and experienced programmers alike. New programmers benefit greatly because they will learn how to construct software properly without having to go through all of the hoops. Experienced programmers will also learn a great deal, as well as be reminded that some of their habits that they've developed over the years can hinder production and cause software development to become more complex then it really is.

Steve writes in a very clean style. It's very easy to read. You don't need to memorize anything in a book like this, instead you just need to gain an understanding of the concepts he brings forth. After reading this book I definitely follow a lot of his advice. When I build a new class, method or what-have-you I get a certain feeling of when it seems right and when something seems wrong. I am now much better at analyzing my code and figuring out what doesn't seem correct and I take his advice I learned in this book to help me to figure out - and correct the problem. After reading this book I feel like a lot of my rough edges as a developer have been rounded out. I feel as if I gained a years worth of experience just by reading this book.

This book is friendly for any software developer. The concepts he presents apply to all languages. This is a book that teaches you how to think about programming better and how to construct good solid code. This is one of the best books I've ever read. If you're even thinking about buying this book, then buy it.

There is a reason that this book is consistently listed as among the top computer programming books. I have not read Knuth's books yet, but I have read a lot of other programming books and of the ones I have read, this is the one I would most recommend. Whether you are fresh out of college or are a seasoned veteran of the code wars, there is likely something in here you could benefit from.

Almost every aspect of software development is covered, from requirements, to how to build functions, to testing, to debugging, to refactoring, and more. Not to be left out are what metaphor to use (he says is should be construction, not farming or growing) and personal character. Those last two are not often found in software development books. The author makes frequent use of data when discussing things like the cost of errors based on when they were found or the best method of quality control.

Some good advice concerns the importance of getting multiple eyes on a piece of code, use of test first development, understanding the problem before attempting to code, use of "the scientific method of debugging," the pseudocode development strategy for writing functions, and the importance of making code readable (by humans).

If you were to find a flaw in it, it would most likely be that it is a little bit dated now. The concepts are still valid I think, but some of the data is pretty old.

a few memorable quotes:

"In general, the principle is to find an error as close as possible to the time at which it was introduced. The further the defect stays in the software food chain, the more damage it causes further down the chain." pg 29

"Managing complexity is the most important technical topic in software development." pg 78

"All in all, I think test first programming is one of the most beneficial software practices to emerge during the past decade and is a good general approach." pg 504

"All things considerd, debugging is an extraordinarily rich soil in which to plant the seeds of your own improvement." pg 538

There are other gem quotes but I was not able to locate them all while writing this review, so you'll need to study the book and find them for yourself...

I encountered the first edition of this book back in the mid 1990's. The opinion I had of it at that time has not changed: Steve McConnell's "Code Complete" is a "must read" book for anyone developing or maintaining software, particularly those in senior and leadership roles - Sr. and Lead Developers, Software Architects, Managers, etc.

"Code Complete" is a distillation of years of experience on Mr. McConnell's part, backed up with research and references from a wide variety of sources, including research papers, journal articles and books. His style is easy to read, he focuses on the practical aspects of the development process, presenting the pros/cons and applicability of each of his recommendations in a solution-focused manner. This isn't a book marketing some theory of what's best, but really concentrates on what works, what doesn't, and how to excel as a software development professional. His points and recommendations are clear and well-supported - and will often be eye-opening material for the reader, no matter how experienced they are in this industry.

"Code Complete" focuses on software development as a discipline, and encourages the reader to think of it as a major component of the overall software development process, including not only the initial specification / design / build / test and deploy cycle, but designing and building the code to enhance its long term "maintainability" and "enhancability". --- The initial deployment of an application is only the first step in its lifecycle: Mr. McConnell makes the strong case that designing and building an application without concern for its long term impact and viability is an expensive mistake.

It's been so long snce I read the first editon "Code Complete" that I cannot compare or contrast the two, but I can say that reading this edition has reinforced and expanded-on many of the practices I adopted years ago as a result of reading this volume and Rapid Development. It is clear the author has kept abreast of the latest research and best practices as the science of software development has evolved since the first edition was published.

When this book first came out, I strongly recommended that my team read it, and have recommended so many times for new developers and especially senior members of subsequent projects I've led. That recommendation stands - and, if anything, is even stronger: frankly, anyone who aspires to a leadership role in software development efforts and who has **not** read this book is needlessly handicapping their ability to succeed in this industry.

I have not heard of this book being used in a college course, which is perhaps understandable, given that it is designed for the benefit of professionals already out "in the field" - but it should be!

No podría describir con palabras lo que esta obra me ha aportado para mi trabajo diario. Resume en casi 900 páginas la experiencia en el desarrollo de software de toda una carrera profesional. Cualquier persona que quiera mejorar como desarrollador de software debería tenerlo en su estantería.

Après avoir appris un langage de programmation et pratiqué quelques années, je recommande chaudement de lire Code Complete. Ce livre a totalement changé la façon dont je programme, je fais maintenant beaucoup plus attention à la qualité du code, pour que le code soit facilement compréhensible. Avec comme résultat qu'il y a beaucoup moins de bugs dès le départ, et un code qui est maintenable à plus long terme, plus facile à modifier, etc.

Ce livre est très complet sur les bonnes pratiques en programmation (pour la partie « construction »), et inclut également des chapitres sur les détails à petite échelle dans le code comme le nom des variables, le nom des fonctions, organiser une suite d'instructions, les bonnes pratiques pour les conditions et les boucles, etc etc. D'autres livres sur les bonnes pratiques en programmation ne vont pas aussi loin dans ces détails, pourtant c'est tout aussi important pour la compréhension du code et éviter des bugs.

teaches how do u write beautiful and cool

code fr

If you're like me then you've probably purchased your fair share of "product and language" books over the years. Those books generally teach you the basics of how to use some company's product or language, but the knowledge doesn't transfer over, and they don't actually make you a better developer.

Insert Code Complete.

This is the book that the software development world has needed for a long time. Instead of focusing on languages, it focuses on general design best practices that are applicable to most languages. Knowing the material in this book will elevate you from the junior developer ranks up to a more senior skill level.

very good book