Writing Solid Code

( 2 )

Overview

Here, from a former Microsoft developer, are super secrets for developing bug-free C programs. You'll see examples of how bugs are caught at Microsoft (actual case histories) and how to use these proven programming techniques to get products to market faster.

Experience Level: All


Explains Microsoft's techniques for developing bug free C programs and provides practical approaches to the prevention and automatic detection of ...

See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (44) from $1.99   
  • New (3) from $17.18   
  • Used (41) from $1.99   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$17.18
Seller since 2014

Feedback rating:

(97)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
PAPERBACK New 1556155514.

Ships from: San Mateo, CA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$65.00
Seller since 2014

Feedback rating:

(162)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$78.77
Seller since 2014

Feedback rating:

(93)

Condition: New
New New condition. Free track. Fast shipping! Satisfaction guaranteed!

Ships from: Media, PA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Page 1 of 1
Showing All
Close
Sort by
Sending request ...

Overview

Here, from a former Microsoft developer, are super secrets for developing bug-free C programs. You'll see examples of how bugs are caught at Microsoft (actual case histories) and how to use these proven programming techniques to get products to market faster.

Experience Level: All


Explains Microsoft's techniques for developing bug free C programs and provides practical approaches to the prevention and automatic detection of errors. Focus is on an in-depth analysis and exposition of not-so-obvious coding errors in the sample code provided. The theme is to answer the questions 'How couild I have automatically detected this bug' and 'How could I have prevented this bug'? Chapters include programmer attitudes, techniques and debugging methodology. A particularly revealing chapter is "Treacheries of the Trade", should be required reading for all C maniacs. The author has been a professional programmer for seventeen years and draws heavily (and candidly) on actual coding prblems and practices based on years of experience at Microsoft. t

Read More Show Less

Editorial Reviews

From Barnes & Noble

Fatbrain Review

Explains Microsoft's techniques for developing bug free C programs and provides practical approaches to the prevention and automatic detection of errors. Focus is on an in-depth analysis and exposition of not-so-obvious coding errors in the sample code provided. The theme is to answer the questions 'How couild I have automatically detected this bug' and 'How could I have prevented this bug'? Chapters include programmer attitudes, techniques and debugging methodology. A particularly revealing chapter is "Treacheries of the Trade", should be required reading for all C maniacs. The author has been a professional programmer for seventeen years and draws heavily (and candidly) on actual coding prblems and practices based on years of experience at Microsoft.
Read More Show Less

Product Details

  • ISBN-13: 9781556155512
  • Publisher: Microsoft Press
  • Publication date: 1/1/1993
  • Series: Code Series
  • Edition number: 1
  • Pages: 256
  • Product dimensions: 7.37 (w) x 9.07 (h) x 0.85 (d)

Meet the Author


Steve Maguire was responsible for valFORTH in 1982, an award-winning FORTH development system that enabled Atari programmers to write high-quality graphics applications and video games. In 1986 Steve joined Microsoft Corporation for the opportunity to work on high-end Macintosh® applications and became best known in the company for his efforts to increase the utility and quality of shared code libraries. As a veteran software design engineer and project lead, Steve spent several of his years at Microsoft working with troubled projects--enabling teams to work effectively and, not incidentally, to enjoy their work.
Read More Show Less

Read an Excerpt


Chapter 8: The Rest IsAttitude

Throughout this book, I've talked about techniques you can use to detect and to prevent bugs. Using these techniques won't guarantee that you'll write bug-free code any more than having a team of skillful ball players will guarantee that you'll have a winning team. The other necessary ingredient is a set of good habits and attitudes.

Would you expect those ball players to have a winning season if they grumbled all day about having to practice? What if they were constantly angry because their salary was a meager $1.2 million per year or were always worried about being traded or cut? These concerns have nothing to do with playing ball, but they have everything to do with how well the players perform.

You can use all of the suggestions in this book to help eliminate bugs, but if you have "buggy" attitudes or coding habits that cause bugs, you're going to have a tough time writing bug-free code.

In this chapter, I'll talk about some of the most common barriers to writing bug-free code. All are easily correctable; often all you need to do is become aware of them.

For My Next Trick, Disappearing Bugs

How many times have you asked somebody about a bug they were fixing and heard in response, "Oh, that bug went away"? I said that once, many years ago, to my very first manager. He asked me if I'd managed to track down a bug in the Apple 11 database product we were wrapping up, and I said, "Oh, that bug went away." The manager paused for a moment and then asked me to follow him into his office, where we both sat down.

"Steve, what do you mean when you say 'the bug went away'?"

"Well, you know, I went through the steps in the bug report, and the bug didn't show up."

My manager leaned back in his chair. "So what do you suppose happened to that bug?"

"I don't know," I said. "I guess it already got fixed."

"But you don't know that, do you?"

"No, I guess I don't," I admitted.

"Well don't you think you had better find out what really happened? After all, you're working with a computer; bugs don't fix themselves."

That manager went on to explain the three reasons bugs disappear: The bug report was wrong, the bug has been fixed by another programmer, or the bug still exists but isn't apparent. His final words on the subject were to remind me that, as a professional programmer, it was my job to determine which of the three cases described my disappearing bug and to act accordingly. In no case was I to simply ignore the bug because it had disappeared.

That advice was valuable in the days of CP/M and Apple IIs when I first heard it, it was valuable in the decades before that, and it's still valuable today. I didn't realize how valuable the advice was until I became a project lead myself and found that it was common for programmers to happily assume that the testers were wrong or that somebody had already fixed the bug in question.

Bugs will often disappear simply because you and the tester are using different versions of the program. If a bug doesn't show up in the code you're using, dig up the version the tester was using. If the bug still doesn't show up, notify the testing team. If the bug does show up, track it down in those earlier sources, decide how to fix it, and then look at the current sources to see why the bug disappeared. Very often, the bug still exists but surrounding changes have hidden it. You need to understand why the bug disappeared so that you can take appropriate steps to correct it.

Bugs don't just "go away."

Too Much Effort?
Programmers sometimes grumble when I ask them to drag out older sources to look for a reported bug; it seems like a waste of time. If it seems that way to you, consider that you're not reverting to earlier sources on a whim. You're looking at those sources because there is an excellent chance that there is a bug and looking at those older sources is the most efficient way to track it down.

Suppose you isolate the bug in those earlier sources and find that the bug has indeed been fixed in the current sources. Have you wasted your time? Hardly. After all, which is better, closing the bug as "fixed" or labeling it as "nonreproducible" and sending it back to the testing group? What will the testers do then? They certainly can't assume that the bug has been fixed-their only two options are to spend additional time trying to reproduce the bug or to leave it marked as nonreproducible and hope that it was fixed. Both options are a lot worse than tracking down the bug in earlier sources and closing the bug as "fixed."


A Fix In time Saves Nine

When I first joined the Microsoft Excel group, the practice was to postpone all bug- fixes to the end of the project. It's not that the group had a cast-iron scroll staked to a wall that read, "Thou shalt not fix bugs until all features have been implemented," but there was always pressure to keep to the schedule and knock out features. At the same time, there was very little pressure to fix bugs. I was once told, "Unless a bug crashes the system or holds up the testing group, don't worry about fixing it. We'll have plenty of time to fix bugs later, after we complete the scheduled features." In short, fixing bugs was not a high priority.

I'm sure that sounds backwards to current Microsoft programmers because projects aren't run that way anymore; there were too many problems with that approach, and the worst was that it was impossible to predict when you would finish the product. How do you estimate the time it takes to fix 1742 bugs? And of course, there aren't just 1742 bugs to fix - programmers will introduce new bugs as they fix old ones. And (closely related) fixing one bug can expose other, latent, bugs that the testing group was unable to find because the first bug was getting in the way.

And those weren't the only problems.

By finishing the features before fixing the bugs, the developers made the product look like it was much further along than it actually was. Important people in the company would use the internal releases, see that they worked except for the occasional bug, and wonder why it was taking Development six months to finish a nearly final product. They wouldn't see out-of-memory bugs or the bugs in features they never tried. They just knew that the code was "feature complete" and that it basically appeared to work.

Fixing bugs for months on end didn't do much for morale either. Programmers like to program, not to fix bugs, but at the end of every project they would spends months doing nothing but fixing bugs, often under much pressure because it was obvious to everybody outside Development that the product was nearly finished. Why couldn't it be ready in time for COMDEX, MacWorld Expo, or the local computer club meeting?

What a mess.

Then a run of buggy products, starting with Macintosh Excel 1.03 and ending with the cancellation - because of a runaway bug list - of an unannounced Windows product, forced Microsoft to take a hard look at the way it developed products. The findings were not too surprising:

  • You don't save time by fixing bugs late in the product cycle. In fact, you lose time because it's often harder to fix bugs in code you wrote a year ago than in code you wrote days ago.
  • Fixing bugs "as you go" provides damage control because the earlier you learn of your mistakes, the less likely you are to re peat those mistakes.
  • Bugs are a form of negative feedback that keep fast but sloppy programmers in check. If you don't allow programmers to work on new features until they have fixed all their bugs, you prevent sloppy programmers from spreading half-implemented features throughout the product-they're too busy fixing bugs. If you allow programmers to ignore their bugs, you lose that regulation.
  • By keeping the bug count near zero, you have a much easier time predicting when you'll finish the product. Instead of trying to guess how long it will take to finish 32 features and 1742 bug-fixes, you just have to guess how long it will take to finish the 32 features. Even better, you're often in a position to drop the unfinished features and ship what you have.

None of these points is uniquely suited to Microsoft development; they are general points that apply to any software development. If you are not already fixing bugs as you find them, let Microsoft's negative experience be a lesson to you. You can learn through your own hard experience, or you can learn from the costly mistakes of others.

Don't fix bugs later; fix them now.
...
Read More Show Less

Table of Contents


Foreword by Dave Moore, Director of Development, Microsoft ..... xi
Preface ..... xvii
Introduction ..... xxi
Chapter 1: A Hypothetical Compiler ..... 1
Chapter 2: Assert Yourself ..... 13
Chapter 3: Fortify Your Subsystems ..... 45
Chapter 4: Step Through Your Code ..... 75
Chapter 5: Candy-Machine Interfaces ..... 87
Chapter 6: Risky Business ..... 111
Chapter 7: Treacheries of the Trade ..... 145
Chapter 8: The Rest Is Attitude ..... 171
Epilogue: Where Do You Go from Here? ..... 195
Appendix A: Coding Checklists ..... 197
Appendix B: Memory Logging Routines ..... 203
Appendix C: Answers ..... 213
References ..... 245
Index ..... 247
Read More Show Less

Customer Reviews

Average Rating 5
( 2 )
Rating Distribution

5 Star

(2)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Posted April 28, 2012

    This is one of the best books on programming ever written. Magui

    This is one of the best books on programming ever written. Maguire concentrates on how to eradicate bugs early in the cycle. At first what he says seems so simple. But these ideas are so powerful, and so well presented, that I'd give a copy to every programmer I know if I could afford to.

    Don't worry that his examples are in C. The ideas transcend the source language. If half of the programmers followed half of his suggestions half of the time, the software industry would undergo a revolution in quality. There is no silver bullet, but these suggestions are so practical. It's just a matter of adopting a few good habbits.

    This book will be a classic. Scratch that. It *is* a classic.

    If you're a programmer, it belongs on your shelf beside _Programming Pearls_, _Code Complete_, and Knuth.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted December 8, 1999

    Great book!

    Its not just for C programmers. I highly recommend it for every programmer that wants better quality code.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)