Code Complete: A Practical Handbook of Software Construction, Second Edition

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 ConstructionThis 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 ScientificMcConnell 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-organizedThis 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 IndustrySome 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.ConclusionOverall, 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.

Use this book to make a decision for you or your company on the programming standards you want to follow. This provides clear statistics and reasoning behind the choices. Don't let it be a guess. This is a well-structured book that is easy to grasp for anyone.This book talks about Java and C++, with some VB and ADA, very little of C# which is what I am using it for, but really the principles are the same for all. It is aimed at programmers and managers, not architects. It covers a lot that is very important to the beginning or advancing programmer, or in my case, someone that wants to create standards for the programmers. Very complete and excellent for that purpose. It was written a while ago, so it needs to be updated. The points it covers are not outdated but still relevant to today. It repeats the main points many times over in different ways, so it is driven in. Excellent as required reading for newer programmers if they want to know why they should follow standards.Also see books (and videos) by Robert "Bob" Martin, and Microsoft online manuals, among other resources that are more current, more detailed, and in my opinion, more boring. Reading from a variety of authors will provide a solid foundation for a decision on the programming standards you want to follow. The goal for all of these books is quality programming with fewer errors.

This book saved my life when I first started coding classes, trying to understand the math behind Binary and how to render complex formulae, not just on paper, but within the realm of computer science. This book is easy to understand and goes over everything step by step, rather than throwing you in with the wolves.By starting with the complexity of binary, moving into early logic gates, then focusing on the serious science behind how code works from your basic programs to complex, the book actively guides you along and encourages you to do experimenting on your own by giving you a detailed rundown without holding your hand.What makes this book special, however, is the depth it goes into - it's almost a thousand pages long ! It might seem daunting, but it's the perfect guide for beginners. No matter if you're going into C, Javascript, Python, or something obscure, this book is an excellent reference to have on hand and an excellent guide to learn from. I highly recommend.

All of the research, and hard won experience - reading this continually keeps me centered - there are too many competing priorities in software development, and what we tend to think is true is what we sort of WANT to be true. We're optimistic, for sure. Highest point: we write the same # of lines of code per day, yet we accomplish more the higher the level of language we are programming in, the highest level language is the DSL ===> Therefore, we should attempt to extract the language (or at least work at it) from the problem domain, and program using the nouns, verbs, and adjectives in that domain. Method names often qualify. Google "Language-oriented programming". Because of THIS book, I knew this 10 to 15 years ago. Mine has lots of post-it notes on the side and top of the book marking my favorite, or most important, things I NEED to keep in my head (and the heads of my managers!). If you're a developer or an electrical engineer, buy this! You won't be sorry.

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.