Steve McConnell's Code Complete 2 is a classic piece of literature in Software Development. I joined a book club for reading this book, and the discussions along the way were some of the most valuable I've had. It was very rewarding to me to see many of the pieces of advice given reaffirming my own coding practices and the way things are done here at SEP, but I certainly took some new information away. One of the main lessons taught throughout the book is that code should be easy to understand. Levels of abstraction, clear class and variable names, information hiding, coding standards - they all leave one less detail you have to juggle in your mind when trying to understand the code you're reading. If you write code that is as close to possible to self-documenting, you'll make your life and everyone else's life that much easier. Mostly this book was just the tip of the iceburg, a good overview of several key topics in the industry. It was very well-researched and cited, though quite a bit of the research was as old or older than I am! There was a recommended reading list at the end of the book which seems very valuable, and I intend to go through it. This book left me with a feeling of 'just getting started' and seems like it would be a good thing for new-hires to read.

Формат: Книга Язык: Русский
Честно признаюсь я являюсь фанатом Стива МакКоннела со времен моего прочтения его "Rapid Development" далеких лет 11 назад. В то время это была книга которая открыла мне глаза на многие вещи в области управления проектами. Данную книгу (Совершенный код) я планировал прочитать тоже достаточно давно, но руки дошли уже когда рабочие обязанности большого кодирования давно не требуют. Книга хороша и действительно понравилось. Единственное в очередной раз заставила задуматься как быстро бежит наша жизнь, т.к. часть материала уже вынужден признать является несколько устаревшей. Именно поэтому 4-ре, а не 5-ть. В любом случае книга является классикой в области разработки программного обеспечения, и думаю ей и останется на горизонте еще как минимум ближайших 10 лет.
К перечтению, думаю да, но кусками когда нужно обновить список полезных идей в конкретной области (например форматирование текста программы и т.п.).

So it’s a #1 must read programming book according to this poll on StackOverflow. That raises quite some expectations, and if you ask me, the book doesn’t really meet them.

I mean, it doesn’t even feel like a proper programming book - it’s written in some “Easy way to quit smoking for dummies” style. Every idea is explained verbosely, then illustrated with some numeric stats, then with a 3D chart, then with some real-life anecdote, then with a reference to a 1973 paper, and finally reiterated in a checklist in the end of the chapter.

But still, this book makes a lot of good points, it’s easy to read, there’s not much prerequisites (“If you’re rusty on polynomials, they’re the the things that look like Ax² + Bx + C”) – maybe it makes sense to read it in high school.

One of the most worthless and dull books I've ever read. Some right ideas and proper approaches are described there indeed but, first, they are obvious and, second, the amount of text one should absorb is 5-10 times greater that needed, in my opinion.

Further, a lot of people recommend this book to beginners which is not worthless but, I would dare to say, dangerous. Many ideas are very controversial, and to yet unformed minds they may be really wrecking.

The idea which I believe can replace the whole book is here: write the code for people to understand. Nothing is beyond that simple truth.

There's not very many topics in the field of software construction that this book doesn't cover! It's an extremely comprehensive guide to everything coding.

Most of the material is still relevant in 2020, especially the parts about programmer psychology and approaches to software.

Some key things are missing due to industry changes:

- a lot of the recommendations around formatting are less relevant since autoformatters like autopep8, go fmt, or clang-format have become popular. Some of the formatting techniques that are good but not recommended by the book because they are a pain to maintain are made much easier by autoformatters.
- expansion of the role of unit testing and test driven development; the book is a light on details for writing tests. A more modern book would go into more details about writing tests, mocks and fakes, etc.
- many examples using VB or C++ without smart pointers are less relevant today then they were in 2004.
- distributed/parallel systems are much more common nowadays. The nature of these systems mean that certain practices that are solid in a single-machine world make less sense in a distributed one where function calls can fail in many more ways, and can be slow over a network.

For some of these there are some solid books out there that you can use to supplement Code Complete. Doesn't stop this from being a really useful book!

This book focuses mainly on the coding and style aspects of software engineering. Any book by McConnell is worth the read.

This is my second time reading this book; the first time was maybe 5 years after the book publication date, and it blew my mind at the time. Now the book is 20 years old, and it shows. The comments on formatting and layout, for instance, are useless in the time of linters and formatters.

I think my review is damaged by the fact that I'm not too experienced to read the book, and there's nothing new to learn. It's not that I remember everything from my first read, it's just that the advice - use good names, test your software scientifically instead of randomly - are now commonplace, at least for a person like me that constantly consumes material about programming.

This can be a good overview, though, of writing good code - and for instilling the mindset that although the end product (the software you are building) is the ultimate value, it can only be built consistently if you pay attention to the process of programming.

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 and Programming Pearls.

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.

I feel like I should have read it earlier in my carrier. It is a good book. But it felt boring to me because I already knew most of the stuff. Did not live up to my expectations because people say it is the Bible of programming. However, I would say that Clean Code by Uncle Bob is more interesting and more useful for me at this point.

Книга полезна разработчикам, которые хотят научиться писать качественный код. Но сама по себе в печатном издании книга очень объемна и поэтому ее не удобно читать или брать с собой, язык в ней академический, много сносок, поэтому под нее так легко уснуть. Похоже на чтение большого советского словаря) Между этой книгой и "Чистым кодом" дядюшки Боба, советую выбрать вторую.

An impressive volume. It must have been amazing back in 2004. There was probably no better single book on software engineering for a beginner at that moment in time. It's impossible not to respect books like these which try to cover the whole ground - there's only a few of them around.

Unfortunately in 2024, huge parts of it are either obsolete, irrelevant, or missing. Across 800 pages, it barely mentions databases. The chapters on testing and debugging are really lacking. Concurrency is another miss, only a few mentions of threads are present. Whole chapters on code formatting and refactoring obsoleted by modern tools.

An experienced engineer will struggle to learn a lot from it, and it would be irresponsible to recommend it to a novice due to all of the above.

I decided to read it as it is frequently recommended along with Clean Code: A Handbook of Agile Software Craftsmanship, Design Patterns: Elements of Reusable Object-Oriented Software and other seminal software books, but it is largely a relic by now.

Очень крутая книга, которая поможет заложить основы качественного кода. Поднимаются полезные темы про конструирование, проектирование. Читать лучше одновременно с изучением языка программирования, чтобы раньше выработать привычку писать правильно. Много времени посвящается принципам как писать хороший и понятный код, как правильно выбирать имена переменных, методов и классов, чтобы код был самодокументирующимся. Однозначно "must read" для тех, кто хочет посвятить свою жизнь написанию кода. P.S. Эта книга никак и никогда не сможет устареть. Эта книга о том, как писать хороший код. Практически везде автор воздерживается от упоминания конкретных технологий. Да и как правила написания понятного кода, которым преимущественно и посвящена эта книга, могут устареть?