Debugging tactics for Project 4 and beyond…

 

·        Program seems to Hang

·        Program is slower than we’d expect

·        Program gives wrong word count

·        Program ends up with wrong tree

·        I’m concerned that program doesn’t work, but nothing obviously wrong

 

v    Print statements.

Ø     Progress (if program slow/hangs)

Ø     Tree/data structure internal structure

§        Follow along

§        Spot check

Ø     Random info on what program is doing.  Functions called.  What case the function is performing (e.g. “performing double rotation”), memory allocations/frees, etc.

Ø     Be sure to flush output, to make sure it appears when it was printed (not buffered, and only printed much later)

v    Debugger

Ø     Step through code after writing

Ø     (hang/slow) Run program for a while, break into debugger & see where it is.

v    Validating asymptotic running time. Count operations, match to actuals.

v    Profiling code.  What is it, why is it a black art?  OS idle loop story.  If lots of time in function:

Ø     Optimize function

Ø     Optimize cache usage

Ø     Make better algorithm (asymptotic)

Ø     What?

v    Assertions (automatic error detection)

Ø     Detect bad inputs, NULLs etc.

Ø     Expensive “SanityCheck” functions

§        Check any invariant you can think of

§        If too expensive – only run occasionally

§        Catches many subtle errors

Ø     Create preconditions, post conditions of functions, & validate them.

Ø     You may still miss errors, that tests would catch

v    Semi-Formal analysis (also Cleanroom techniques).  “Semi-Formal”, since usually full formal proofs aren’t cost effective.

Ø     e.g. NY Daily News replication logic/ debugging Jim’s Map Engine code

Ø     Analyze your code to prove correctness

§        Catches many subtle errors

§        You can actually prove correct, theoretically

§        Promotes better coding, to help you prove correct (if you’re code is very poorly structured, you’ll find it impossible to convince yourself that it’s correct

Ø     Leads to good assertions/sanity checks to make

v    Code reviews

Ø     e.g. with your partner

Ø     Even your mom works

Ø     Catches flaws in reasoning you might not get alone

v    Books on software engineering

Ø     Accessible & practical:

§        MS Press: Writing Solid Code, Code Complete, Rapid Application Development (except the silly insistence about talking about “rapid development” all the time).  OO Software Design by Betrand Meyer.

v    Designing test cases (black box testing)

Ø     Common cases

Ø     Boundary cases

Ø     Extremes: huge, tiny, sorted input for splay tree…