Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Books Media Programming IT Technology

Classic Coding Tome Updated 48

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Classic Coding Tome Updated More

Classic Coding Tome Updated

Comments Filter:

  • What level is this appropriate for? (Score:2, Interesting)

    by 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? (Score:5, Informative)

      by Quarters ( 18322 ) on Monday July 05, 2004 @09:51PM (#9617554)
      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.
      • 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.

    • 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

    • 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 readabilit

  • Pair Programming. (Score:3, Interesting)

    by eddy ( 18759 ) on Monday July 05, 2004 @09:49PM (#9617546) Homepage Journal

    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.

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

      • Re:Pair Programming. (Score:4, Interesting)

        by B1 ( 86803 ) on Tuesday July 06, 2004 @11:18AM (#9621826)
        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.
    • 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.

  • Great book,,, (Score:4, Interesting)

    by Alomex ( 148003 ) on Monday July 05, 2004 @09:50PM (#9617548) Homepage
    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.


  • 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

    • Re:Many obvious statements (Score:5, Interesting)

      by SlowMovingTarget ( 550823 ) on Tuesday July 06, 2004 @01:12AM (#9618543) Homepage

      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.

      • 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:Many obvious statements (Score:4, Interesting)

          by SlowMovingTarget ( 550823 ) on Tuesday July 06, 2004 @07:45AM (#9620044) Homepage

          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.

          • 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 :)

            • Re:Many obvious statements (Score:1, Informative)

              by Anonymous Coward
              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

        • 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.
        • 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.
          • Changing the tab size from the default 8 is a very bad idea. Using spaces is preferable.
          • 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

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


        You.. insensitive clod!

  • Testimonial (Score:4, Informative)

    by baruz ( 211342 ) on Tuesday July 06, 2004 @12:28AM (#9618382) Homepage
    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.
    • 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.
  • 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?

    • Re:Other good books? (Score:1, Insightful)

      by Anonymous Coward
      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.

      Getti

    • 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

    • Re:Other good books? (Score:3, Insightful)

      by epepke ( 462220 )

      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 sec

    • Re:Other good books? (Score:4, Interesting)

      by pragma_x ( 644215 ) on Tuesday July 06, 2004 @04:32PM (#9625440) Journal
      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.
    • 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 havi

    • I wrote an article on my website [zx81.org.uk] 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

  • Software Project Survival Guide (Score:4, Insightful)

    by Anonymous Coward on Tuesday July 06, 2004 @07:44AM (#9620039)
    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 [amazon.com]

  • Used for CS classes (Score:3, Insightful)

    by kingbyu ( 682024 ) on Tuesday July 06, 2004 @10:51AM (#9621524) Homepage Journal

    The old version of this book was used as a textbook for CS 240 [byu.edu] 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 (Score:5, Insightful)

    by kabz ( 770151 ) on Tuesday July 06, 2004 @11:55AM (#9622263) Homepage Journal
    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.
  • Of programming books, I like Kernighan & Ritchie's The C Programming Language [bell-labs.com] (_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

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close