This book should be mandatory for all computer science student and developer to be. A great receipe of writing Clean code and software craftmanship.

Ce livre devrait être lu par bon nombre d'étudiant en informatique et de développeurs professionnel afin d'améliorer de manière globale la qualité de code source produit ainsi que sa conception.
Dans cette ouvrage, nous retrouvons plusieurs points essentiels du développement logiciel, que se soit des techniques afin de concevoir une architecture globale propre ou encore des techniques afin d'améliorer la qualité du code source. Cela passe par de nombreux exemples que donne l'auteur sur son expérience passé, ainsi que de nombreux chiffres et statistiques permettant de mieux cerner ce que nous dit l'auteur.
Je ne spoilerais pas le contenu du livre, pour forcer les développeurs intéresser à le lire d'eux-même. Cependant, je le conseille dans sa version original Code Complete pour ceux n'étant pas anglophobe, car la traduction française, bien que bonne, souffre parfois de soucis, en particulier au niveaux de la définition des termes non "traduisible" de l'anglais. De plus, il arrive qu'il manque certains mots ou que les phrases n'aient pas de sens, encore une fois due à la traduction de cette ouvrage.

This book is a behemoth, and also fantastic.

It’s well-written, carefully structured, and comprehensive. There’s a lot of content in its ~850 pages, but it’s generally concise and to the point.

It covers everything from the nitty-gritty details of variable naming and indentation style to the much broader themes of software development, such as managing complexity, iterating, and collaborating.

In my ~6 years as a software engineer, I have collected a toolbox of principles, instincts, tips, and tricks. This book mostly reflected all those back to me, but with better rationales and hard data.

There were a few sections that felt a bit dated - but generally I was surprised how relevant most of it still is given how much programming has changed in the ~20 years since this was published.

This book was a pretty good read. Most of what is discussed is extremely valuable information. Although with only 5 years of experience I felt like many of the points that Steve brought up were fairly obvious once you've been working as a Software Developer. If you are new to programming, want to move to a more professional level of programming or just plain have plenty of time on your hands this is a great book. However, if you already have a fair amount of experience developing software professionally, I would suggest you look elsewhere for good reading.

TLDR: I read this book as a very novice programmer with a background in the natural sciences (not computer science). It was very useful for me as a first introduction to Object-Oriented Programming. I now feel more prepared to dive into more specialised books about programming.

I will give you a brief overview of my background, so you understand my context going into this book. I have a master's degree in physics and mathematics and a Ph.d. in experimental physics. During my time at the university, I used MatLab for data analysis and plotting. I was never taught MatLab, but was expected to lean as needed. After finishing the ph.d. I got a job in a small start-up as a machine learning engineer. I had prepared for such a position by taking courses on Coursera and playing around with Python and its modules for Data Science and Machine Learning. Still only focusing on analysis.

So most of my code tended to live in single files and I had never felt the need to create a class.

I started reading this book because I wanted to have a better understanding of the systems that will be using my analyses.

This book is very long. However, I think the author has succeeded in writing a very readable book, which makes it possible to read it from cover to cover in a relatively short time span (I read it in a month). I generally enjoy reading, so this was not a problem for me, but if you are in a hurry, this might not be the book for you.

The book is well structured, so if you are more familiar with the general concepts than I was, you can probably skip quite a lot. If you are not familiar with the concepts, the author has you back and gives several examples and explain the concepts at length. Each chapter contains check-lists at the end, which served as useful summaries, but should also work quite well as a tool for skimming the different chapters.

The code snippets in this book are in C++, Java, and Visual Basic. I knew none of these languages, but this was not a problem because it his points apply to writing object-oriented code in general.

This book focuses on the problems that arise when you work on a software projects with tens or hundreds of programmers. I work on a small team (less than 5 people), so I don't experience most of these problems on a day to day basis, but it was interesting to read about none the less.

After having read this book I feel better prepared to dive into other books about good programming style. I have ordered Clean Code by Robert C. Martin and The Practical Programmer by Andy Hunt and Dave Thomas. It will be interesting to see how these books compare to Code Complete.

_The_ book about the craft of programming. Not only should every programmer read it, they should reread it every several years. In the detailed view this book is an examination of all aspects of software construction, down as far as the minutia of loops and conditionals. But in the broad view there is a golden thread running through this book that ingrains in your mind: "Code doesn't just happen. You _choose_ how you write code. Strive to choose wisely."

A lot of interesting stuff in it but also a lot of stuff that is simply not as important as it was in the past. It's not a cover to cover book to me but I will have a look at it again once I need to dig deep into a specific topic.

Required reading for those that approach software developer as a craftsman would, as an artisan would.

This is probably in the top 5 of every good programmer's list of books that every programmer-to-be should read. I actually keep a copy of this in my bathroom.

Code Complete is a massive work, so this summary is, necessarily, very high level. It is not a book that one can absorb completely in one reading, but one can absorb its high level themes (summarized nicely in the second to last chapter).

"Conquer Complexity". High quality code manages complexity. No one can think of all of the levels of abstraction needed to fully understand a program at once; just admit it and try to make your code less complex. Complexity can be managed at every level of the development process from having a well thought out high level design to choosing good variable names.

"Pick Your Process". Having a process is important. It does not matter exactly what the process is; in fact, the process should be tailored to the problem at hand. The purpose of a process is to allow for coordination between people. When a project is small (1, maybe 2 people), then it is the talent of the individual that matters most. When a project is large, it is managing communication that matters most.

"Write Programs for People First, Computers Second". Computers do not care about programs being readable, but people do, and people are going to read your programs many time. Readable code has a plethora of advantages including lower error rates, being easier to debug and modify, and having shorter development time. Make code readable first, and only optimize when you can make measurable improvements to measurable performance bottlenecks.

"Program into Your Language, Not in It". Do not limit your programming by the features your language supports. Write libraries that will support the programming features you want for the problem at hand. One example McConnell gives writing an assertion library if your language does not support assertions.

"Focus Your Attention with the Help of Conventions". Conventions, like processes, do not matter in their particulars. Some conventions are better than others, but for the most part, conventions tend to be arbitrary. However, having conventions makes code easier to read and modify because a convention can communicate a lot without using much space or requiring much thinking.

"Program in Terms of the Problem Domain". This is a particular method of managing complexity. Higher level code should be supported by lower level code that hides implementation specific details from the higher level code. When done well, this makes the code easier to read and easier to modify. Even at the construction level, this can be done by choosing good class names and abstractions, factoring code into methods to maintain a common level of abstraction, and choosing good variable names.

"Watch for Falling Rocks". Look out for warning signs, such as classes with an abnormally high number of defects. These warning signs do not necessarily mean that something is wrong with that part of the program, but they are a good indicator that you should be a little bit suspicious. These warning signs could show up after construction (error rate) or during construction (compiler warning, indications from your self or other that your program is hard to understand).

"Iterate, Repeatedly, Again and Again". In addition to being my favorite section heading in the book, this principle emphasizes that iteration is appropriate at all points of the software development process. Requirements are rarely fixed in stone, bugs are always present, and developers can always find a better way to rewrite code. Iteration gives all of these improvements a chance to actually make it into the product under development.

"Thou Shalt Rend Software and Religion Asunder". No one convention, process, or tool set is the be all and end all of software development. Developers should be wary of absolutes and try to avoid blind faith in the processes they use. Solutions should be adapted to the problem at hand, not vice versa. The key to keeping an open mind and becoming effective and flexible is experimentation. Be willing to try new things, measure the effectiveness of those experiments, and be willing to change based on the results.

Those are the high level principles. These principles occur over and over again through the seven parts of this book. The first part, titled "Laying the Foundation" discusses the general process of software development and the role of construction (a.k.a. programming) in that process. Construction is important, according to McConnell, because it is the only part of the software development process that absolutely must happen to produce a working software project. Construction is also an area that, traditionally, has not has as much attention to it as other areas (such as high level design or testing). However, McConnell stresses that all parts of the development process are important in creating a successful project and gives pointers throughout the text to resources that discuss other parts of the software development process in more depth. He notes that pre-construction planning is particularly important since no amount of good construction and through testing can save a bad design.

Section two is "Creating High-Quality Code". This section introduces a point emphasized again and again throughout the book. Software's "Primary Technical Imperative" is managing complexity. High quality code exposes people reading it to consistent levels of abstraction separated by clear boundaries. Complexity is managed by minimizing the essential complexity one has to deal with at any given time and trying to keep accidental complexity from spreading throughout the code base. High quality classes and routines provide consistent abstractions, document their assumptions, and check their invariants defensively; they fail sooner rather than later. Even a simple class or routine is worthwhile if it decreases the complexity of reading the code where it is used.

One of the most practically useful facts I got out of Code Complete was learning about the "Pseudocode Programming Process". This process is a way of developing code by starting with detailed pseudocode. When constructing a program, a developer should (iteratively) write pseudocode that is high level enough to be in the domain of the problem but low level enough for translation to real code to be nearly mechanical. Developing pseudocode ensures that the developer understands the problem at a low enough level for implementation, encourages the programmer to think about error checking before implementing the nominal path through the code, may indicate what when to factor code into separate routines (and suggest names for those routines). Those parts of the high level pseudocode that the developer decides to leave in provide automatic, high level commenting of code.

The third section is entitled "Variables" and discusses the effective use of variables. The chapters in this section discuss data initialization (do it close as close to the declaration as possible), variable scope (keep it as small as possible), limiting variables to a single purpose, effective variable names (keep them specific, use a naming conventions), and tips for using fundamental and more complex data types.

Statements are covered in section four called, not surprisingly, "Statements". This section discusses methods for effectively organizing and using straight line code, conditionals, and loops as well as more exotic control structures such as exceptions, gotos, and various table driven control structures. This section discusses how deep nesting of control structures tends to make code complex. If possible, it should be avoided by restructuring the code or factoring the nested code into its own routine. The more paths there are through a code fragment, the more complex it is; the number of paths a developer must consider at a single time should be minimized.

Section five, "Code Improvements" discusses a mishmash of techniques for improving code. It discusses software quality, collaboration, developer testing, debugging, refactoring, and code tuning. One key point of this section is that the goals of a certain construction project should be clear. Some goals are bound to go against each other, and if developers do not know which are most important, they will do a bad job of trying to optimize all of them at once. The most obvious example of this tendency is that aggressive optimization may make code less readable and prevent beneficial refactorings. This section also points out that code reviews, testing, debugging, refactoring, and code tuning all have the potential to improve code quality, but it is when they are used thoughtfully in unison that their potential is maximized.

Section six, "System Considerations" discusses some higher level issues in constructing a system. As project size increases, project quality and development speed tend to go down in a faster than linear manner. This is because as the project increases, more and more overhead gets taken up by managing communication and more details tend to get lost in the cracks. It is for this reason that having a process and conventions becomes more important on large projects; the more that is automatic, the less that quality and and development time will suffer. This section also discusses how to manage programmers and essential tools that every developer should know about and use. This section also discusses several integration processes and emphasizes that which process is right depends on the project being developed.

The final section of Code Complete is "Software Craftsmanship". This section talks about good practices in actually structuring code and how to write good, effective comments and code that documents itself as much as possible. This section also describes the importance of personal character in becoming an excellent developer. McConnell posits that intelligence is less important than other personal characteristics such as humility, curiosity, intellectual honesty, communication and cooperation, creativity and discipline, effective laziness, and good habits. The point emphasized throughout the discussion on personal character is that a good developer needs to be happy and willing to learn from other developers and be willing to admit when their are right and wrong if they want to earn the trust and respect of others.

A useful part of the final section was McConnell's summary of where to find more information. In particular, he presents "A Software Developer's Reading Plan" reproduced below for my future reference. Note that the plan should be supplemented to the needs and interests of particular developers.

Introductory level:

Adams, James L. Conceptual Blockbusting: A Guide to Better Ideas, 4th ed. Cambridge, MA: Perseus Publishing, 2001.

Bentley, Jon. Programming Pearls, 2d ed. Reading, MA: Addison-Wesley, 2000.

Glass, Robert L. Facts and Fallacies of Software Engineering. Boston, MA: Addison-Wesley, 2003.

McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.

McConnell, Steve. Code Complete, 2d ed. Redmond, WA: Microsoft Press, 2004.

Practitioner level:

Berczuk, Stephen P. and Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Boston, MA: Addison-Wesley, 2003.

Fowler, Martin. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3d ed. Boston, MA: Addison-Wesley, 2003.

Glass, Robert L. Software Creativity. Reading, MA: Addison-Wesley, 1995.

Kaner, Cem, Jack Falk, Hung Q. Nguyen. Testing Computer Software, 2ed. New Yor, NY: John Wiley & Sons, 1999.

Larman, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2d ed. Englewood Cliffs, NJ: Prentice Hall, 2001.

McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996.

Wiegers, Karl. Software Requirements, 2d ed. Redmond, WA: Microsoft Press, 2003.

"Manager's Handbook for Software Development," NASA Goddard Space Flight Center.


Professional level:

Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2d ed. Boston, MA: Addison-Wesley, 2003.

Fowler, Martin. Refactoring: Improving the Design of Existing Code. Reading, MA: Addison-Wesley, 1999.

Gamma, Erich, et al. Design Patterns. Reading, MA: Addison-Wesley, 1995.

Gilb, Tom. Principles of Software Engineering Management. Workingham, England: Addison-Wesley, 1988.

Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.

Meyer, Bertrand. Object-Oriented Software Construction, 2d ed. New York, NY: Prentice Hall PTR, 1997.

"Software Measurement Guidebook," NASA Goddard Space Flight Center.

For more details and up to date reading lists see www.construx.com/professionaldev (requires an account, free with purchase of code complete).

Other interesting things from a quick skim of the bibliography:

Baecker, Ronald M., and Aaron Marcus. 1990. Human Factors and Typography for More Readable Programs. Reading, MA: Addison-Wesley.

Various works by Kent Beck

Various works by Barry Boehm

Dijkstra, Edsger. 1965. "Programming Considered as a Human Activity." Proceedings of the 1965 IFIP Congress. Amsterdam: North-Holland, 213-17. Reprinted in Yourdon 1982 (Writings of the Revolution).

Disjkstra, Edsger. 1972. "The Humble Programmer." Communications of the ACM 15, no. 10 (October): 859-66.

Knuth's Literate Programming.

Paul Oman and Curtis Cook. "The Book Paradigm for Improved Maintenance" and "Typographic Style is More than Cosmetic".

Schneiderman, Ben. 1980. Software Psychology: Human Factors in Computer and Information Systems. Cambridge, MA: Winthrop.

Spinellis, Diomidis. Code Reading: An Open Source Perspective.

Various by Gerald Weinberg.

Praktični vodič kroz sva područja programerskog zanata. Svako poglavlje dira pojedino područje i puno je savjeta i praktičnih primjera. Autor koji se sam bavi razvojem i vođenjem projekata zastupa tezu da je programerska glava premala za količinu informacija kojom se barata u pojedinom projektu.

Programer mora kontrolirati svoju okolinu od nivoa bitova pa do zajedničkog rada više jedinica preko mreže. To je devet nivoa složenosti. Pisanjem čitljivog koda, držanje standarda, korištenje prikladnih alata lakše se savlada kompleksnost i prelazi sa nivoa na nivo.

Pročitao sam knjigu, našao sam izvučeni popis svih check lista https://www.matthewjmiller.net/files/... i sada pregledavam poglavlje po poglavlje konjige po potrebi tokom rada.

Even the most recent edition of Code Complete appeared nearly 16 years ago: very old for a programming book; but it does have its own Wikipedia article. The work has serious gaps despite its considerable size, but the underlying principles remain as true as ever.

The broad scope of this book makes it elusive to capture in a review.

In lifecycle management, McConnell advocates a traditional waterfall model, arguing that errors are more expensive the earlier they are committed and the longer they are allowed to proliferate: don't design until know the requirements; don't code until you have a consistent design. This flies in the face of more recent tendencies towards agile development, which considers continuous changes in requirements and in design to be just facts of life.

In coding practices the most important lesson that I am taking away is this: programming (in anything but assembler) is writing for a human readership. When you experience a conflict between writing convenience and reading convenience, always side with the latter. This holds even if you are only "writing a program for yourself": yourself in 2 years will be a different person from yourself now. And I will never use i and j als indexes in a double loop again.

McDonnell likes code reviews but only if they are sufficiently formalized to become inspections. He also encourages pair programming because (and only if) it combines insights of people from different backgrounds.

Despite the considerable size of the work, there are now serious gaps.

The gap that contributes most to the risk of this book becoming outdated, is the total absence of development frameworks. Nobody develops systems from scratch anymore. Quality standards, testing strategies, and especially design are seriously informed by the availability of frameworks. If your team has to spend time re-inventing MVC or similar design patterns, even with the Gang of Four in hand, you are probably bleeding money.

Not entirely unrelated to the absence of frameworks, I find it hard to understand why there is no mention of two-tier or three-tier applications. Business software based on a relational database and offering a web interface is no longer just one of several options (was it, back in 1993?): it is the de facto standard.

Also, dear Steve or editors: please start to include Python and Javascript already. Less and less organizations do C++ anymore, and most of the reasons for that actually follow from your book!