When I tweeted about my intention to read Code Complete, I got a couple of warning replies. I found out that the book is "a waste of time", "big white elephant on your desk" and "a dull book to while away the time in one's old age".
But such feedback didn't disturb me because Code Complete is listed in books to read by Hexlet School of Witchcraft and Wizardry where I studied programming.
The book was easy and fun to read. Yes, McConnel's humor is fire. So I laughed many times while reading a serious work about programming. But first thing's first.
The book received Jolt Award in 1993, a prestigious award by Dr. Dobb's Journal for books on software development.
It also received positive reviews from Martin Fowler, Grady Booch, and other famous software engineers and computer science experts.
Hardback version of 900 pages weighs more than 1 kg. Probably, that is what frightens people away from this work. Let's open the book and find out if there is anything to be afraid of?
Code Complete is still relevant even though it was first published almost 30 years ago. This book contains very little information that could ever get out of date. McConell discusses fundamental coding principles that are unlikely to change within the next few years.
The code examples are mainly in Visual Basic, Java and C++. But the book's main points make sense regardless of specific languages.
There is a difference between programming into the language and in It.
Programming in your language limits your programming thinking only to the constructs that the language directly supports. If the language tools are primitive, the programmer's thought will also be primitive. Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language. — Steve McConnel.
I had the feeling that there is not that much code in Code Complete.
The author talks about coding in general and occasionally goes to specifics and illustrates his points with examples.
He pays big attention to the process of development — from requirements gathering and choosing the technology to coding, testing, debugging, refactoring, and optimization.
The book starts with an explanation of why metaphors are important. One of the metaphors offered is building construction.
Metaphors help both developers and any people they work with, such as managers, designers, and clients.
They occur on the stage of requirements gathering and designing.
It is easy to explain with building construction metaphors. If you make mistakes when laying the foundation, it will be difficult to fix them when the building is nine floors high.
These are the problems that can be defined only by partially or fully fixing them. I bet every programmer had a situation when a manager asked you to define the time needed for your task. And you explain that it is impossible because you actually have to solve the task first. This is what McConnel calls a dirty problem.
Managing complexity is the main technical aspect of software development. McConnel quotes Dijkstra, who pointed out that no one's skull is really big enough to contain a modern computer program. This means that software developers shouldn't try to cram whole programs into our skulls at once. We should try to organize our programs in such a way that we can safely focus on one part of it at a time.
This was a huge insight for me.
For some software robustness is more important than correctness, for some conversely.
For instance, safety-critical software for a spaceship would require a high level of correctness. And we would have to sacrifice correctness in favour of robustness.
Please, leave comments about your interpretation of this point and if you agree with it.
Why Isn’t Sam Coding Anything? Non-tech people suppose that programmers must be coding nonstop. Clients and bosses get nervous while programmers are planning or working on requirements.
McConnel gives us an easy way to fight WISCA phenomenon. Just keep a straight face and keep the source-code editor window open.
By the way, on the sense of humor. McConnell inserts jokes on nearly every page. They are witty and specific. This is the famous programming humor in its purest form.
I found the book helpful because it’s all about fundamentals. It helps to look for the forests before we look for the trees. And generalize problems and tasks.
The book sure contains plenty of practical and specific examples or recommendations. The parts about variable naming, operators and mastery of programming are pure concentrated usefulness.
I was happy that a big and serious book is written in easy language. Even examples in unfamiliar languages turned out to be comprehendible and useful.
What I didn’t like is how quickly I finished the book. I also didn’t like the chapter on programming tools.The choice of compiler, IDE and other tools depends on which specific technology is used.
Well, my conclusion is predictable. The book is worth the money and the time spent. It is more about basics in general rather than a handbook with practical guidelines. Thanks to Code Complete I gained a deeper understanding of coding in general. I started to see things that were out of my attention.
Don’t be put off by the thickness of the book. I guarantee you’ll let out a chuckle many times when reading it.