Slashdot Mirror

← Back to Stories (view on slashdot.org)

Classic Coding Tome Updated

Posted by timothy on from the new-words dept.

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."

48 comments

  1. Re:Missing Something? by damiangerous · · 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!"

  2. What level is this appropriate for? by Anonymous Coward · · 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?

    1. Re:What level is this appropriate for? by Quarters · · 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.

    2. Re:What level is this appropriate for? by eddy · · 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.
    3. Re:What level is this appropriate for? by kabz · · Score: 1
      This book is appropriate for beginning programmers, though they should probably stay in the shallow waters of this book.

      Once you have some programming under your belt, this book will give you many best practices and, as another poster comments, will give you the reasons for those best practices. Programming lore is all very well, but this book gives solid evidence for why. Example, the sections on code structuring and indentation backup the recommendations with solid evidence and examples of how readability of the code can be improved. If you follow the book, the programmers that read your code and attempt to modify it in the future will love you.

      One of my favorite aspects of this book is that it also emphasizes simplicity.

      SLIGHTLY OFF TOPIC: If I could do one thing to help the programming profession (apart from making everyone read this book), it would be to emphasize simplicity, unit testing and remove some of the BS about the 3 and 4 level tiered architectures that are emphasized by people with a vested interest in large expensive projects. Any system that needs more than one set of metadata and/or generates more than one layer of code from any one set of metadata is too damn complex.

      One layer of abstraction should be enough for anyone.

      --
      -- "It's not stalking if you're married!" My Wife.
  3. Pair Programming. by eddy · · 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.
    1. Re:Pair Programming. by jmccay · · Score: 0, Troll

      I thought it was a joke when I first saw the book. Think about it. Code complete coming from Microsoft? How complete is their code if it's full of security holes? I don't think I will read this book, or any similar, from Microsoft.

      --
      At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
    2. Re:Pair Programming. by B1 · · 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.

    3. Re:Pair Programming. by anomalous+cohort · · Score: 1
      I read the previous edition, and my feeling then was that it, between the lines, sang the gospel of Pair Programming

      I read that book but I didn't get that impression. Code Complete certainly emphasizes the importance of code reviews. Pair programming is not really a code review although I can see how you might think of it as a code review while you type. Real code review should happen after the programmer thinks that (s)he is done.

    4. Re:Pair Programming. by jmccay · · Score: 1

      If you are correct, then maybe they should pass out free copies to the programming.

      --
      At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
  4. Great book,,, by Alomex · · 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.

  5. You are correct, sir. by neutralstone · · Score: 1

    Though personally I am of the opinion that "M$ iz teh sux0r!", I nonetheless found the first edition to be full of insights and advice that authors of Free Software would do well to heed. McConnell r0x0rs. Buy the second edition from B&N.

  6. Many obvious statements by Futurepower(R) · · Score: 1, Insightful


    To me, the book looks like a big disappointment. I downloaded Chapter 5. There are numerous obvious statements like these:

    Design Is About Tradeoffs and Priorities

    And:

    How to Attack Complexity
    Overly costly, ineffective designs arise from three sources:
    A complex solution to a simple problem
    A simple, incorrect solution to a complex problem
    An inappropriate, complex solution to a complex problem

    1. Re:Many obvious statements by SlowMovingTarget · · 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.

    2. Re:Many obvious statements by archeopterix · · 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.

    3. Re:Many obvious statements by 12357bd · · Score: 1

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


      You.. insensitive clod!

      --
      What's in a sig?
    4. Re:Many obvious statements by SlowMovingTarget · · 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.

    5. Re:Many obvious statements by Anonymous Coward · · Score: 0
      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.
      If I recall correctly, the first edition also targeted self-taught programmers, people who had the experience but had come by it haphazardly and may have accumulated some bad practices along the way--my story. Somewhere in the preface or introduction, but it's not to hand right now, so I can't verify.
    6. Re:Many obvious statements by Anonymous Coward · · Score: 0

      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.

      Con:
      - After a couple of nested blocks, it severely limits the number of meaningful characters one can put on a line, which encourages terse code and therefore can limit readability.

      Your second pro has little value. If you misread an indentation of 4 characters, then either the function's too long, or you need your eyes checked.

    7. Re:Many obvious statements by jfx32 · · Score: 1

      Actually, if I remember correctly the Linux kernel code uses tabs, which normally default to 8 spaces. Most editors allow you to change the way tabs appear on screen. I think Linus has a rule about not having more than three levels of nesting in code as well.

    8. Re:Many obvious statements by L1TH10N · · Score: 1

      Indentation should be done with TABS and avoid spaces altogether. This will allow a user to define indents the way they like it. If they want 2 spaces then set the tab width to 2 spaces. If 4 spaces then set the tab width to 4 spaces width. 8 spaces then set the tab width to 8 spaces. I can't understand why this does not happen.

      --
      Yet another ironic recursive statement.
    9. Re:Many obvious statements by CaptnMArk · · Score: 2, Insightful

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

    10. Re:Many obvious statements by ACPosterChild · · Score: 1

      I would like to see a few of the samples they used. I'm interested in the sample length and whitespace %. I think 6 spaces would work better when there is ample whitespace and comments. If the code is short and packed tightly, 2-4 spaces would be plenty to keep the nested logic apparent. But, spread it out over 2-3 pages and add comments, and I think I'd have a hard time telling the indent level.

      Then again, maybe a test would prove me wrong. That's why I'd like to see a sample :)

    11. Re:Many obvious statements by Anonymous Coward · · Score: 1, Informative
      That is one of the nice things about the book. Everything is documented, and you can go to the source for more information. In this case, the source is:

      Miaria, Richard J., et al. 1983. "Program Indentation and Comprehensibility" Communications of the ACM 26, no 11 (November): 861-67

  7. Testimonial by baruz · · 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.
    1. Re:Testimonial by astrojetsonjr · · Score: 1

      I've had one since the first printing also. I'v taught classes at the local university using it, and did a 12 week lunchtime session at work. It's great material, its things about programming that have never (and most likely will never) change.

  8. Other good books? by identity0 · · Score: 1

    I'm a programmer who knows a couple of languages, but has never taken an advanced CS theory or project management class. I'd like people's opinions on what books to read to make me a better coder and help me understand the broad concepts, not just doing rote stuff in a new language.

    Is UML useful? How about books on secure programming? Are design patterns a good tool? Will learning things like assembly or Lisp teach me anything useful?

    1. Re:Other good books? by Anonymous Coward · · Score: 1, Insightful

      If I were you I would just try to write as much code as possible. Studying CS theory will make you good at CS theory. Studying project management will make you good a project management. Continuing to write more code and possibly learn more programming paradigms (logic, functional, etc.) will make you a better coder.

      If you wanted the body of an olympic swimmer would you practice basketball or swimming?

      Maybe you are asking the wrong question. Maybe you want ot be good at proj. man. or theoretical CS.

      Getting back to books, I've never read a book on general programming technique that was any good. You have to be the sort of individual who doesn't learn from mistakes if you get anything useful out of those books. The only computer book passage that floated my boat was the intro to the Gödel language book. Basically, it was an apology for logic programming that hit all the right buttons for me and convinced me that social proof was saying Turing/von Neumann but my heart was saying Prolog. Two years later I'm only now planning to wean my income off C and PowerPC assembler and start problem solving with Prolog.

    2. Re:Other good books? by MobyTurbo · · Score: 0
      Is UML useful? How about books on secure programming? Are design patterns a good tool? Will learning things like assembly or Lisp teach me anything useful?

      All of these (well, I don't know UML, and I am only planning on learning patterns) are useful. I'd especially reccomend learning LISP and assembly. LISP will teach you new methods of abstraction above and beyond OOP, as well as "programmable programming language" ideas that can be used to understand language-writing with less pain. (For more on why LISP is good, see Paul Graham's site.

      Assembly language is very useful because you find out how the computer works at a low level. When you know that, it will help you make your higher level language programming more efficient since you'll have a better idea of how it will work once it is compiled or interpreted. That's why Knuth's "The Art of Programming" has its examples written in an imaginary assembly language.

    3. Re:Other good books? by epepke · · 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.

    4. Re:Other good books? by Anonymous Coward · · Score: 0

      "Design patterns" is a bit of a classic. It will make you think.

    5. Re:Other good books? by pragma_x · · 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.

    6. Re:Other good books? by ACPosterChild · · Score: 1

      If you want to understand the "broad concepts" of computer programming, I'd have to 2nd Knuth's programming series. Specifically, you should learn data structures and their performance, aka O(n) or Big-O (i.e., why looking up an item in a hash or binary tree is much faster than searching through an array or linked list for large data sets, and how large a set you need before you need to implement a more complex data structure).

      That topic is enough to keep you busy for awhile, and the most important in having programs that run reasonably. It can be easy to make O(n) mistakes in general program structure, and not know why your program runs so slow.

      For other broad "how to program" topics, the topic book is probably a good place to start. Design patterns are a good way to stretch your brain, too (search for Design Patterns and Gang of Four for the seminal work). Learning languages like Lisp, ML, Prolog in addition to OO languages (Scheme being probably about the only true OO language, Ruby is probably good, too) will also expand your mind.

      A great place to start might be http://www-mitpress.mit.edu/sicp/sicp.html . It's a book (free online if you want) titled Structure and Interpretation of Computer Programs and it uses Lisp/Scheme as it's teaching tool. I keep meaning to read it, but I think it covers much that you might learn with Knuth's series. It would at least be a good intro.

    7. Re:Other good books? by stephend · · Score: 1

      I wrote an article on my website about this.

      That was a while ago though! I'd also second the recommendation for Pragmatic Programmer and I think Extreme Programming Explained (also reviewed on my website!) is worth reading even if you don't like XP.

      --> Stephen

  9. Re:Why? by The+Clockwork+Troll · · 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
  10. Excellent for the self-taught... by Big+Sean+O · · 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.
  11. Software Project Survival Guide by Anonymous Coward · · 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

  12. Used for CS classes by kingbyu · · 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.

  13. Code Complete by kabz · · 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.
  14. my favorite tome by Doc+Ruby · · Score: 1

    Of programming books, I like Kernighan & Ritchie's The C Programming Language (_K&R C_) best, mainly because it's short. But my favorite tome is Bruce Schneier's Applied Cryptography. It's focused on encryption, and security, but that's a great way to make the basic principle of programming implicit in one's programs: write a program that does what you expect, rather than what someone else can get it to do instead. And when you skim the 80% that is purely cryptological (though never cryptic ;), it's only 57% as big as _K&R C_.

    --

    --
    make install -not war

  15. Use of Tabs by SeanDuggan · · Score: 1

    Actually, I had at least one professor in school who felt the opposite way and enforced it. In his class, no tabs were allowed, the reason being that different editors would display different tab levels. With spaces for indents and monospaced font, everything was guarenteed to line up. Since he was the same professor who took off a point every time you used a single character variable name that was not a counter for a loop (i, j, or k) or a position (x, y, or z), we obeyed him. *shrug* To each their own, I guess. Most decent editors freely convert between the two.

    --
    This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
  16. I'm not reading something from a Micro$oft employe by Anonymous Coward · · Score: 0

    Unlike the facist fuckers at micro$haft, the people at GNU release their books for Free (as in sex) for people to edit and contribute.

    I wish slashdot would stop reporting on every little piece of shit microsoft does. Everyone knows that each and every employee in Redmond is a moron, and everything M$ makes SUCKS THE BIG ONE.

    They are also monitoring us.