BOOK　REPORT:Code Complete

BOOKNAME::Code Complete

AUTHOR::Code Complete

Here's a download site for this book:
http://www.verycd.com/topics/147539/

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.

When beginning reading Code Complete, 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 book is 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 useful quotes from the book:

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.