Code Complete Book Review (part 2 of 7)

I am continuing my book review of the great Code Complete. This second part focuses on design in software construction. As I am reviewing Code Complete I have also been reading Refactoring by Martin Fowler. In his book he states that great design comes about through refactoring and polishing your design. Steve McConnell supports design up front.

In my experience I think that up-front design is necessary and focuses your development. However, my best design has come from refactoring. In addition, Code Complete discusses design at many different levels, from system and subsystem all the way down to routine level. Even if your class hierarchy will change down the line, well designed routines can help make your refactoring much easier.

Creating High-Quality Code

  • Design in Construction
    • Design Challenges
      • Designs is about tradeoffs and priorities
      • Design involves restrictions
      • Design is nondeterministic
      • Design is a heuristic process
      • Design is emergent
    • Key Design Concepts
      • Levels of Software Design
      1. System
      2. Subsystems/packages
      3. classes
      4. data & routines
      5. internal routine design
    • Design Building Blocks: Heuristics
      • Mimic real world objects. When doing this, try to form consistent abstractions.
      • Hide as much information as possible. Only expose enough information to run the system
      • Isolate pieces of the system likely to change.
      • Identify common design patterns
    • Design Practices
      • Design Checklist
      • Iterate. Design a small part of your system, then branch out from there. There are two approaches to be considered, top-down and bottom-up. 
  • Working Classes – Class Quality Checklist
    • Class Foundations: Abstract Data Type – The easiest way to identify classes in your system is to look at collections of data. Group together related data and their operations to form a class.
    • Good Class Interfaces – Make sure you only implement one ADT per class. This has been a helpful rule of thumb to decide if I am "done" refactoring a class.
    • Design and Implementation Issues
      • Containment
      • Inheritance
      • Member Functions and Data
      • Constructors
    • Reasons to Create a Class
        • Model real-world objects
        • Model abstract objects
          • Reduce complexity
          • Isolate complexity
          • Hide implementation details
          • Limit effects of changes
          • Hide global data
          • Streamline parameter passing
          • Make central points of control
          • Facilitate reusable code
          • Plan for a family of programs
          • Package related operations
          • Accomplish a specific refactoring
      • High Quality Routines
        • Here’s a summary list of the valid reasons for creating a routine:
          • Reduce complexity
            • Introduce an intermediate, understandable abstraction
            • Avoid duplicate code
            • Support subclassing
            • Hide sequences
            • Hide pointer operations
            • Improve portability
            • Simplify complicated boolean tests
            • Improve performance
          • In addition, many of the reasons to create a class are also good reasons to create a routine:

            • Isolate complexity
            • Hide implementation details
            • Limit effects of changes
            • Hide global data
            • Make central points of control
            • Facilitate reusable code
            • Accomplish a specific refactoring
            • Design at the Routine Level
            • Good Routine Names
            • Routine Size
            • Parameters in a Routine
          • Defensive Programming
            • Defensive Programming Checklist
            • Invalid Inputs
            • Assertions
            • Error Handling
            • Exceptions
            • Barricade your code
            • Debugging Aids
            • Defensive code in Production
            • Being Defensive about Defensive Programming
          • Pseudocode Programming Process – This is the design tool I was taught in school and it best maps to creative writing. You draft and rewrite your system until writing the code is easier than writing another step. This has the benefits of
            • Identifying any areas of misunderstanding, this ensures that you understand the system and have done a risk analysis early in the system.
            • Providing top level documentation for your classes or routines
            • "Getting the ball rolling" in decomposing an intricate problem
            • Providing a stepping stone towards "Literate Programming"

        This material is copied and/or adapted from the Code Complete 2 Website at This material is Copyright © 1993-2007 Steven C. McConnell. Permission is hereby given to copy, adapt, and distribute this material as long as this notice is included on all such materials and the materials are not sold, licensed, or otherwise distributed for commercial gain.

        Leave a Reply

        Name *
        Email *