WritingSolidCode.pptVIP

Writing Solid Code Zubin Huang Reference Writing Solid Code, Steve Maguire, Microsoft Press, 1993, ISBN 1-55615-551-4 Mission BUGS, BUGS and BUGS … Who is responsible for the BUGGY Program Find and fixing bugs was DEVELOPER’s responsibility Zero defects? Can we success? How? Feasibility “I don’t expect programmers to write flawless code every time they sit at the keyboard, but I do believe that it’s possible to keep bugs out of the master sources.” -- Steve Maguire Every Bug Found How could I have automatically detected this bug? How could I have prevented this bug? Better Testing? NO! Use tools to find bugs Enable all optional compiler warnings Use Tools (Purify, BoundCheck, lint, mportal) to catch bugs that your compiler may miss If you have unit tests, use them Assert Yourself Undefined vs Steer Clear Use assertions to catch illegal uses of undefined behavior Get bugs in assertion? Should fix the program? Fix the assertion? Document unclear assertion. Assert Yourself … /* Check both outputs for validity */ ASSERT( pcRet == pcDisasmAlt(pc, opc)); ASSERT( compare_opc(popcRet, opc) ==SAME); DO NOT disturb the surrounding code in an unexpected way in ASSERT FORTIFY YOUR SUBSYSTEMS How are programmers going to misuse this subsystem, and how can I detect these problems automatically There’s No Need to Know Suppose a new programmer creates a lost memory block? The checks kick in New Programmer (NP) not know what a lost memory block is NP not need to know that for the checks to work NP can track down the failure Guideline: Strive to implement transparent integrity checks You Don’t Ship the Debug Version You use the debug version to find bugs You use the release version to please customers … MS result: the debug version of your application – packed with assertions and subsystem tests – should run at about half the speed of your ship version. Guideline: Don’t apply ship version constraints to the debug version. Trade size and speed for error detection. Step Thro