Classic Coding Tome Updated

Re:Missing Something? by damiangerous · 2004-07-05 12:08 · Score: 3, Insightful

It's published by Microsoft Press. BFD. Read up on the author, then come back and tell us he's not eminently qualified to write a book on the subject. Of course, this is an update, the original from 1993 has already been widely acclaimed for a decade so you're going to have to come up with a more convincing argument than "d00d, M$ iz teh sux0r!"

What level is this appropriate for? by Anonymous Coward · 2004-07-05 13:21 · Score: 2, Interesting

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? by Quarters · 2004-07-05 13:51 · Score: 4, Informative

Read the Preface .pdf. It spells out exactly what the author thinks Experienced Programmers, Technical Leads, Self-Taught Programmers, and Students will get out of the book.
Re:What level is this appropriate for? by eddy · 2004-07-05 13:57 · Score: 2, Interesting

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. [...]

--
Belief is the currency of delusion.

Pair Programming. by eddy · 2004-07-05 13:49 · Score: 3, Interesting

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.

--
Belief is the currency of delusion.

Re:Pair Programming. by B1 · 2004-07-06 03:18 · Score: 4, Interesting

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,,, by Alomex · 2004-07-05 13:50 · Score: 3, Interesting

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.

Testimonial by baruz · 2004-07-05 16:28 · Score: 4, Informative

I learned to program in grade school, taking little projects from Computer Recreations and implementing them in MS Basic for the Macintosh. This was not the most conducive way to learn to program in a disciplined fashion, and yet in the early nineties I found myself having to program to spec and to schedule for various people, and not doing too well. It was not until I picked up the first edition of this gem that I truly understood that the craft could be approached as a discipline, that code quality does matter to software quality, and that a well-constructed program is more maintainable and extensible.

If all McConnell did was slap a new cover on it, it would be worth looking into if you've never read it. But he put several chapters out last spring for review, comment, and critique, including some all-new chapters. I'm definitely picking it up when it becomes available.

--
He was a verray parfit gentil knight.

Re:Many obvious statements by SlowMovingTarget · 2004-07-05 17:12 · Score: 5, Interesting

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 by archeopterix · 2004-07-05 19:58 · Score: 2, Interesting

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.

Re:Why? by The+Clockwork+Troll · 2004-07-05 20:03 · Score: 4, Funny

Why is a new release of a programming book, designed to render its predecessor obsolete, greeted with such enthusiasm here while a new release of Windows or Office, also designed to render its predecessor obsolete is greeted with derision?

You're not comparing apples to apples.

If your comparison were to be fair, Code Complete would be in its 13th edition with each new edition bringing a rearrangement of chapters for no apparent reason, 10 new pages of content at most, and entire sections devoted to tools nobody can use or figure out without purchasing the supplemental Inside Code Complete, 13th edition and subscribing to the CCDN (Code Complete Developers' Network).

--

There are no karma whores, only moderation johns

Excellent for the self-taught... by Big+Sean+O · 2004-07-05 23:43 · Score: 2, Interesting

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.

--
My father is a blogger.

Software Project Survival Guide by Anonymous Coward · 2004-07-05 23:44 · Score: 4, Insightful

I can also strongly recommend McConnell's Software Project Survival Guide (amazon link). I think all software team leaders and project managers should read this book as it packs a lot into a small number of pages. Amazon link: Software Project Survival Guide

Re:Many obvious statements by SlowMovingTarget · 2004-07-05 23:45 · Score: 3, Interesting

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.

Used for CS classes by kingbyu · 2004-07-06 02:51 · Score: 3, Insightful

The old version of this book was used as a textbook for CS 240 at BYU, which is an advanced programming /slash/ C++ course.

I find it great that some professor is actually teaching coding standards. Imagine my surprise of discovering JavaDoc commenting after haven taken 3 Java classes and not one of them ever mentioned JavaDoc.

I haven't taken CS 240 yet, but I plan to this fall. I already talked to the professor about the textbooks he plans to use, and he said that if they came out with the new edition (which they did) then he would probably use the new edition for class. This means though that current students with the book now will have a hard time selling the book, and future students will have a harder time finding used book deals on it. I guess I should start saving my college student pennies.

Code Complete by kabz · 2004-07-06 03:55 · Score: 5, Insightful

This book is the best programming book I have ever read.

I believe that my own productivity increased by about 50% at least after reading it.

Code Complete answers many of the questions that nag the working programmer, and busts through much of the BS that people spout about programming.

The book covers a huge range of material, from code formatting and style, to how to build teams. Clue: don't put all the programmers no one else wants in a team to build an important project ;-)

The writing style is friendly and peppered with hilarious case studies such as 'Escape from Gilligan's Island', where the same mistakes happen over and over again.

Everyone who has worked on large programming projects will recognise some of these anecdotes. In one case I watched from start to finish as an 'experienced consultant' ruined a perfectly good project with secrecy over his bad and undocumented code. All the warning signs were there. If the manager had read this book, a programming catastrophe might have been averted.

I have bought this book a few times, and given it to management in-duh-viduals to read. Sometimes it helped.

If you are a programmer or a manager, or just interested in software, buy this book and read it. I guarantee you will learn something.

--
-- "It's not stalking if you're married!" My Wife.

Re:Other good books? by epepke · 2004-07-06 05:05 · Score: 2, Insightful

Is UML useful?

It depends on what you mean by "useful." If you're working in a shop that requires UML, and you need to communicate with people, then it's useful. The big problem with UML is that a truly bad design looks just the same as a good design. A much better test of the quality of design is to describe it in English. If it can't be done easily, then it's probably a bad design.

How about books on secure programming?

I haven't met any of these that I like. There are lots that tell how to secure against various exploits, but few that explain the basics.

Are design patterns a good tool?

They aren't a tool. They are an attempt at establishing a common vocabulary. The worst thing you can do with a design pattern is think, "That's cool! I'll implement it."

Will learning things like assembly or Lisp teach me anything useful?

Yes, definitely. Both will make you a better programmer no matter what language you use. Assembly because it gives you a feel for what a compiler can do directly and what takes work, and LISP because it encourages a way of looking at tasks that you probably haven't thought of.

Donald Knuth's The Art of Computer Programming should be in your library, even if you don't read it cover-to-cover. Donald Norman's The Design of Everyday Things should also be there. And, of course, the revised edition of The Mythical Man-Month

The thing is that most of the ideas in programming are quite old, but they get repackaged as new things. Once you understand the old stuff, the new stuff all falls into place.

There are a few invaluable things that CS can give you. Algorithms, for instance. There exist plenty of classical solutions to everyday problems that most modern programmers just don't know about. Proving the complexity of algorithms is also incredibly useful. You won't prove every algorithm you produce in your life, but it will give you a feel for it. Graph theory is also quite useful.

Re:Other good books? by pragma_x · 2004-07-06 08:32 · Score: 3, Interesting

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.

Re:Many obvious statements by CaptnMArk · 2004-07-06 19:26 · Score: 2, Insightful

Changing the tab size from the default 8 is a very bad idea. Using spaces is preferable.

19 of 48 comments (clear)