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.