Review: Code Complete 2

kuniga.me > NP-Incompleteness > Review: Code Complete 2

Review: Code Complete 2

01 Jun 2016

code-complete

In this post I’ll share my notes about the book: Code Complete 2, by Steve McConnell. The book has great information about several aspects of Software Development, but it’s quite long: 862 pages.

This is not a summary of the book by any means, but rather points that I found interesting, novel or useful. I hope the reader find it useful or at least that it inspires you to go after the book for more details on a specific topic.

I’ve written down bullet points about each chapter, some of which I added my own thoughts/comments.

Chapter 1 - Introduction

Chapter 2 - Metaphors

Chapter 3 - Prerequisites (gathering requirements)

Chapter 4 - Construction Planning

Comments: Adopting early technology also helps with recruiting. Programmers like new technology.

Chapter 5 - Design

Comments: Hiding information properly is an art. It doesn’t help to stick as much code as possible into private methods if the public methods are not intuitive and require diving into implementation details.

Chapter 6 - Classes

addEmployee()
firstItem()

The second one is closer to implementation detail. In general, the closest to the business level the abstraction is, the better.

Chapter 7 - Routines

Comments: in the past I used to think of routines as ways to share code. This sometimes conflicts with readability and the linux principle. This is especially true when you group several routines calls into one because it’s used in two places, but they’re not cohesive enough to name it the routine clearly, so we end up using vague terms such as init, prepare, preprocess, cleanup, etc. Nowadays I prefer being verbose (i.e. repeating the lines in both places) in favor of readable code.

Chapter 8 - Defensive Programming

Comments: the barricade is pretty nice, it helps reducing the complexity in the main code by not having to handle too many corner cases and also centralizes where bad data is handled, so you don’t risk double or triple checking the same conditions in several places.

defense

Chapter 9 - Pseudocode Programming Process (PPP)

Chapter 10 - Variables

Chapter 11 - Variable naming

Chapter 12 - Fundamental Data Types

Chapter 13 - Unusual Data Types

Chapter 14 - Organizing code within a routine

Comments: I also like memoized functions to break dependencies. If B depends on A being run, I create A as a memoized function that B can call no matter if it had been called already.

Chapter 15 - Conditionals

Comments: I tend to do the opposite in favor of the early returns: this helps reducing nesting and clear up corner cases first - this works well when the handling of the exception case is simple.

Chapter 16 - Loops

Chapter 17 - Unusual Control Structures

Chapter 18 - Table-driven methods

Chapter 19 - General control issues

a < 0 || a > 10 do a < 0 || 10 < a

Chapter 20 - Quality assurance

Chapter 21 - Collaborative Development

Chapter 22 - Testing

  int a = 10; // 1
  ...
  if (x < a) { // 2
     ...
  }
  int b = a + 1; // 3

In this case we would add two tests: one that exercises lines (1) and (2) and another that exercises (1) and (3).

Chapter 23 - Debugging

Chapter 24 - Refactoring

Chapter 25 - Code Tuning

Chapter 26 - Code Tuning Techniques

“The impact of unmeasured code tuning on performance is speculative at best, whereas the impact on readability is as certain as it is detrimental.”

Chapter 27 - Program Size Affect Construction

Chapter 28 - Managing Construction

This chapter seems to be more targeted to managers, but also useful to developers to understand the “other side”.

“If someone on a project is going to define standards, have a respected architect define the standards rather than the manager. Software projects operate as much on an expertise hierarchy as on an authority hierarchy.”

Chapter 29 - Integration

Chapter 30 - Programming Tools

11054398564_58a9322fa1_o

Chapter 31 - Layout and Style

Chapter 32 - Self-documenting code

Chapter 33 - Personal Character

Traits that the author considers important in a good programmer:

Analyze and plan before you act: dichotomy between analysis and action. Programmers tend to err of the side of acting.

The most important work in effective programming is thinking, and people tend not to look busy when they’re thinking. If I worked with a programmer who looked busy all the time, I’d assume he was not a good programmer because he wasn’t using his most valuable tool, his brain.

Traits that the author thinks are overrated:

Chapter 34 - Themes in Software Craftsmanship

Conclusion and review of thee book

My message to the serious programmer is: spend a part of your working day examining and refining your own methods. Even though programmers are always struggling to meet some future or past deadline, methodological abstraction is a wise long-term investment - Robert W. Floyd.

Chapter 35 - Where to find more information

Books recommendation:

Conclusion

This book contains a lot of valuable information and I’ve incorporated several of his ideas in my day-to-day work, especially regarding making code easier to read.

The suggestions in the book are often backed by hard data, making them more credible. Sometimes the advice is subjective, even contradicting, but he often provides several points of view or alternatives, so that the reader can make their best judgement of when to use them.

Tags: review software engineering