Classic Coding Tome Updated

Tim Halloran writes "Steve McConnell has updated his book 'Code Complete' a 960 page language agnostic tome about code construction. This is the best book of its type I've ever encountered and the update is welcome (as the first edition is over a decade old...I suddenly feel as I'm getting old :-). More information, and a sample chapter are here. As a programming team lead I have provided this book to team members to get them critically thinking about how they write code."

Comments

What level is this appropriate for?

[Anonymous Coward]

Would this book be useful as an introductory text? I'm reading throguh one of the same chapters, and it seems good so far. But would it worth the coin for someone new to programming?

Re:What level is this appropriate for?

[eddy]

Well, how serious are you about software development? I'd answer "yes", but it depends on how rich you are in time and money and where you're going.

I did have some reservations (or minor nits) about the original, would be interesting to hear if these have been addressed:

[...] I could comment on the fact that he writes about implementing his own crypto and does not caution the reader that they shouldn't do that unless they are cryptographers, or atleast know what they're doing. I could mention that he on page 433 claims, without reservation, that a debugger will execute every statement on a single line of source, as if it were a unit. I could wonder about the omission of the generally lauded practice of writing [pointer comparisons] such that the constant is on the left hand side of the comparison operator. [...]

Pair Programming.

[eddy]

I read the previous edition, and my feeling then was that it, between the lines, sang the gospel of Pair Programming. Anyone else got that impression? I don't think it was ever mentioned specifically in that edition, though I could certainly be wrong on that.

Re:Pair Programming.

[B1]

I have a copy of 'Solid Code', also put out by Microsoft. It's actually a very sensible, no-nonsense book about writing dependable code. The book is well written full of good advice, regardless of the fact it's published by 'Microsoft Press'.

My only reservation about the book is the author's insistence on using Hungarian Notation.

In all fairness, I think there are plenty of people at Microsoft that know how to write good solid code. They probably have a few incompetent coders on staff, but I think generally their coders are very talented. They do have pretty high standards for their people.

Many of Microsoft's infamous software flaws can be traced back to their emphasis on features and ease of use, rather than quality. After all, if you ran into a bug, it was probably something you could fix by buying the next version.

Recently, they've started to focus more on quality--I hope this translates into actual results and not just lip service.

Great book,,,

[Alomex]

I first came across this book by accident, while browsing the otherwise dismal "computer books" section in a bookstore. It didn't take more than a few pages to realize that this book was a major accomplishment. I still recommend it to my programer friends and look forward to reading the update edition. Sure lots of the things covered are fairly straightforward, but is good to have them listed in a single place and in an orderly fashion. On top of that every so often it covers something that had escaped you which makes it even more valuable.

Re:Many obvious statements

[SlowMovingTarget]

If you read the first edition, one the things it did was give weight to things that are "obvious."

It's obvious that indents should be no more than 4 spaces and no less than 2 spaces, and that only one option should be used consistently throughout a given body of code. The cool thing was that the book gave you the results of studies that backed up this "obvious" statement. It put programming lore on a factual basis.

I came to the first edition of Code Complete with several years of programming experience under my belt. I had much the same response to it as I did to Pragmatic Programmer, namely that it helped me understand why I had developed some of the habits I had. It also helped me find those areas where I still needed polish.

Both of these books aimed at teaching how to program well, not how to program. I hope this second edition is up to the standard of the first.

The book is aimed at developers who may have graduated from some college class that taught them the Java language (for example), but did not teach them how to use it properly. Browsing through the sample chapter you mention, it seems to stay true to the character of the original. I notice on page 21 of the PDF that he discusses studies on information hiding. You and I may know the value of encapsulation, but the book points to facts that back up our lore on the subject.

The upshot of this fact is that Code Complete looks great in a references section of document that makes a technical argument, in much the same way The Mythical Man Month does (a stunning achievement in IT literature... it's ~ 30 years old and still right for the most part). All three of the books I mention here are worth reading simply because they capture good programming practice in a way no other piece of writing has.

Re:Many obvious statements

[archeopterix]

It's obvious that indents should be no more than 4 spaces and no less than 2 spaces [...]

It's not obvious. Linux kernel code uses 8 spaces.

Cons:
- It limits the block nesting level within a proc.

Pros:
- It limits the block nesting level within a proc.
- It makes it hard to misread the indent.

Excellent for the self-taught...

[Big Sean O]

I found this book after learning programming on my own for a few years. I thought it filled in the gaps on things that weren't described in 'plain old' language books.

I suppose if you had a professors, cow-orkers, or friends that you could learn this book wouldn't be as useful.

I keep the book is nearby on the 'top shelf' of my bookcase. I don't use it much anymore, but it and 'the Pragmatic Programmers' are among the books that most influenced me as a programmer.

Re:Many obvious statements

[SlowMovingTarget]

As I was typing the post my first thought was of this particular convention in the Linux kernel code. The rule to follow there is to stay consistent with the existing body of code. But FYI, here's the relevant bit from the first edition of Code Complete:

Indentation has been shown to be correlated with increased programmer comprehension. The article "Program Indentation and Comprehensibility" reported that several studies found correlations between indentation and improved comprehension (Miara et al. 1983). Subjects scored 20 to 30 percent higher on a test of comprehension when programs had two-to-four-spaces indentation scheme than they did when programs had no indentation at all.

The same study found that it was important to neither under-emphasize nor over-emphasize a program's logical structure. The lowest comprehension scores were achieved on programs that were not indented at all. The second lowest scores were achieved on programs that used six-space indentation. The study concluded that two-to-four-space indentation was optimal. Interestingly, many subjects in the experiment felt that the six-space indentation was easier to use than the smaller indentations, even though their scores were lower. That's probably because six-space indentation looks pleasing. But regardless of how pretty it looks, six-space indentation turns out to be less readable. This is an example of a collision between aesthetic appeal and readability.

Code Complete, pp. 409, 410

So while the Linux kernel code may indeed aesthetically prevent the bad coding practice of deeply nested C code, it likely runs the risk of being harder to understand. Once again, this is the sort of thing I always thought was cool about the original book. It ascends above religious wars with hard data, while clearly identifying the whole subject as a religious issue... there's a little cartoon sign in the book at the beginning of that chapter.

Re:Other good books?

[pragma_x]

I'd reccomend the Pragmatic Programmer, as it covers a wealth of best practice while maintaining a good dose of humor through some very entertaining rehtoric.

Design Patterns, as was mentioned here already is a *must have* (IMO) for any developer, even if you're coding Cold-Fusion scripts all day. After all, there are other ways to take advantage of the object-oriented philosophy w/o an OO language.

UML is a great communication tool (language), but it can't do everything, even though it tries. Ultimately, it really just helps standardize the world of bubble-drawings, inheritance diagrams and object interaction sketches and use-cases that everyone used to publish before 1995.

IMO, a referece is only as good as you find yourself opening it, and a langauge like this only as good as those around you understand it. I'd reccomend a good lightweight reference and mabye a tutorial or three to get familiar with the bulk of UML. The reference will come in handy later when you encounter symbols or diagrams that you may need to translate/learn quickly. UML, in its entirety is a very deep topic with a lot of ground to cover, so be prepared for a time investment if you want to go for the whole thing.

Outside of all this, I'm afraid the truely advanced stuff is all hiding away in the ACM's conference archives, the IEEE's archives and innumerable studies and papers from CS Phd's and the like. A lot is available online, but you can still find some concepts and studies that have stood the test of time at the library (Dead Tree Format). Your local University's mathematics section is a good place to start.

Working in another language enough to understand the nuances and advantages to its grammar can do wonders for expanding how you tackle problems. To truely get the most out of a new language, you need to approach it as a cross-training exercise and try to learn what you can from what doesn't cross the language barrier, and carry everything else with you. This is like football players learning ballet: knowing how to pirouette won't get you more touchdowns, but learning balance and grace will help you dodge tackles and blocks.

For example: In the case of learning ASM after C, you'll understand in far more depth the impact of iteration vs recursion and pass-by-value vs pass-by-reference. But if you just learn one language all by itself, for itself, you're not going to acquire the kind of depth and understanding that you seek.