Code Complete
(A detailed book review)
Book Information
|
|
Code CompleteA Practical Handbook of Software Construction Microsoft Press, 1993, 857 pages ISBN 1556154844 |
Summary
Code Complete is programming classic. It is 900 pages of intelligent and fascinating discussion about coding software.
Introduction
This book is not about how to program in a particular language, how to use SSADM or other methodologies. This book is about improving the way that you work throughout the development cycle.
The author describes the development process as being everything from the technical, detailed design stage, right through to the integrated testing. This is the jurisdiction, or domain, of the programmer.
With an immense bibliography, the author has combined theories, common practices and hard data to make his points. Sometimes, however, he completely contradicts the commonplace practices. Here is a man who supports established practices, but backs his own convictions where they differ. Subjectivity surfaces on occasion with statements such as "If you come across one of these clowns, ask him the following". On the whole, there is the distinct impression that the author was motivated to write this book in order to help programmers, and related IT staff.
References to personal experience punctuate bibliographic references in order to put the point across. Clearly this man knows his stuff, and is not simply trying to pedal his own particular point of view that has never been proven. The author has developed his techniques over time, and has then decided to write a book on the subject. Where the purpose of his methodologies is nebulous, he backs them up with hard data.
Summary of Points
Here is a summary of the points that I believe are particularly of note.
1. Software Accretion Method. The author recommends an accretion approach to software construction. This means the method of initially building the most basic working system possible, and then adding on layers piece by piece.
2. Prerequisites. It seems obvious, but it is important to have all of the requirements in place before time is spent on detailed design or construction. Ensure that all the system prerequisites are outlined. The author also describes the "Myth of Stable Requirements". The important thing is to manage changes properly.
3. Use of PDL. This is a section that I found particularly fascinating, in the section dealing with designing Routine. PDL stands for Programming Definition Language. PDL is a language similar in purpose to pseudo code, but is more abstract, using statements that resemble spoken English. The method here is to design a routine in PDL and then use the statements to form the basis of the routine. The PDL statements become the comment lines in the routine, and the functionality is filled in between the comments. This method allows the design of the routine to remain a constant, and to be clearly visible when viewing the code.
4. Routines and Modules. The author spends a lot of time describing quality. This is particularly apparent with coding modules and routines. The author lists good and bad reasons for writing routines, and how to write quality routines and modules.
5. Abstraction and Naming. One of the most recurring themes throughout the book is abstraction. This theme is prominent when the author discusses naming standards. For routines, modules, variables, constants and literals, abstract naming standards are extremely useful. They allow code reading to be made easier, and help to describe the program in the problem domain.
6. Layout and Style. After mentioning quality in routine design and use, the author outlines the correct layout and styles of coding to use. Good and bad examples are shown, and the reasons for the choice of layout are mentioned. Also mentioned is how much of a sensitive area layout and programming styles are, including the hundred years war that is the GOTO debate.
7. Management. The book is not only focused on the programmer. There is a section that is for the attention of the Programming Manager. This deals with everything from planning and scheduling right through to managing the people. When discussing planning, the importance of measurement is also mentioned. Apart from progress, quality also needs to be measured. Several methods for measuring are suggested, including formal and informal reviews.
8. Testing. There are more opinions and suggestions for testing than just about anything else in software development. This book is no exception, however, the author describes testing in sections of Unit testing, Functional Testing, Integration Testing and Live Testing. Methodologies for all of these areas are outlined.
9. Optimization. There may be times when a program needs to become more streamlined. The author discusses the use of code tuning techniques, and the most important issue of when to optimize and when to leave it alone.
Table of Contents
1. Understanding Software Construction
2. Prerequisites to Construction
2.7. Time to spend on Pre-Requisites
4.1. Valid Reasons to Create a Routine
4.5. How Long Can a Routine be?
4.7. Use of Routine Parameters
4.8. Consider the use of Functions
5.1. Modularity: Cohesion and Coupling
5.2.1. Secrets and the Right to Privacy
5.2.3. Barriers to Information Hiding
5.3. Good Reasons to Create a Module
6.1. Introduction to Software Design
6.2.1. Choosing Components to Modularize
6.4. Comments on Popular Methodologies
6.4.1. When to use Structured Design
6.4.2. When to use Information Hiding
6.4.3. When to use Object Oriented Design
7.1. Reasons to create your own Data Types
7.2. Guidelines for creating Data Types
7.3. Making Variable Declarations Easy
7.4. Guidelines for Initializing Data
8.1. Considerations in choosing good names
8.1.1. The Effect of Scope on Variable names
8.1.2. Computed-Value Qualifiers in Variable Names
8.2. Naming Specific Types of Data
8.3. The Power of Naming Conventions
8.4. Informal Naming Conventions
9. General Issues in Using Variables
9.4. Relationship between Data Structures and Control Structures
9.5. Use each Variable for one purpose only
9.6.2. Reasons to use Global Data
9.6.3. How to Reduce the Risks of Using Global Data
9.6.4. Use Access Routines instead of Global Data.
11. Organizing Straight Line Code.
11.1. Statements that must be in a specific order
11.2. Statements who's order does not matter
13.1. Select the kind of Loop to use.
13.3. Creating Loops form the inside out.
13.4. Correspondence between loops and arrays
14. Unusual Control Structures
15.4. Taming Dangerously Deep Nesting
15.5. The Power of Structured Programming
15.6. Control Structures and Complexity
16.3.3. BEGIN-END Block Boundaries
16.4. Laying Out Control Structures
16.4.1. Fine Points of Formatting Control Structures
16.5. Laying Out Individual Statements
16.5.2. Using spaces for clarity
16.5.3. Aligning Related Statements
16.5.4. Format Continuation Lines
16.5.5. Use Only One Statement Per Line
16.5.6. Laying Out Data Declarations
16.8. Laying Out File, Modules and Programs.
17.2. Programming Styles as Documentation.
17.4.3. Commenting Data Declarations
17.4.4. Commenting Control Structures
17.4.6. Commenting Files, Modules and Programs
17.4.7. Using the "Book" Paradigm for commenting
18.2.3. Analyzing Code Quality
18.2.4. Restructuring Source Code
18.4. Tool-Orientated environments.
18.5. Building your own tools.
19. How Program size Affects Construction
19.1. Effect of Project Size on Development Activities.
19.2. Effect of Project Size on Errors
19.3. Effect of Project Size on Productivity
20.1. Encouraging Good Coding.
20.1.1. Considering in Setting Standards.
20.2. Configuration Management
20.2.1. What is configuration Management?
20.2.2. Software Design Changes
20.3. Estimating a Construction Schedule
20.3.3. Influences on Schedule
20.3.4. Estimation vs. Control
20.3.5. What to do if you are behind
21.1. Treating Programmers as people
21.2. Variations in performance and quality
22. The Software Quality Landscape
22.1. Characteristics of Software Quality
22.2. Techniques for improving Software Quality
22.3. Relative Effectiveness of techniques
22.3.1. Percentage of Errors found
22.3.2. Cost of finding defects
22.3.3. Cost of fixing defects
22.5. General Principle of Software Quality
23.1.1. Reviews complement other QA techniques.
23.1.2. Reviews remove corporate structure.
23.1.3. Reviews assess Quality and Progress.
23.1.4. Reviews also apply before construction.
23.2.1. Roles During Inspections
23.2.2. Procedure for Inspections
24.1. The Role of Unit Testing
24.2. Testing During Construction
24.3. The Testing Bag of Tricks
24.3.2. Structured Basis Testing
24.3.4. Equivalence Partitioning
24.3.9. Use test cases that allow easy manual checks.
24.4.1. Which routines contain the most errors?
24.4.2. Errors by Classification
24.4.3. Proportion of Errors Resulting from faulty construction