1. CSC 107 - Programming for Science Lecture 16: Debugging

2. Question of the Day What is smallest number of matchsticks moved to make this equation valid (using roman numerals) + =

3. Today’s Goal Today we are going to be talking about “debugging”  What it does means and what it should mean After today, should have additional strategies to develop working solutions

4. Origin of the Word “Bug” KING EDWARD: So, lie thou there. Die thou, and die our fear; For Warwick was a bug that fear'd us all. -- Henry VI. Part III. Act V. Scene II. bug meant a specter, ghost, other otherworldly source of fright

5. Origin of the Word “Bug” (2) From late 19 th century, “bug” meant defect or problem in electronic connections First computer bug was more literal

6. Debugging a Program Debug program when not working properly  Could be an error in the code  Program logic could be incorrect  Design may not allow certain features Better to find a bug as early as possible  Easiest to fix when still on paper  Understood best immediately after writing it This is NOT just a programming issue  Debugging is best when starting early

7. Starting the Program How to start a program 1. Determine what the problem is asking 2. Come up with a good set of tests cases Test cases crucial for working programs  After all, how else can you know it works?  Include a range of different possible inputs  For each input determine the correct output

8. Test Cases Round decimal to nearest whole number  Input is a single decimal number  Many, many possible test cases I had 5 categories of test cases  Positive rounding up -- 3.6. 14.5. 99.9999  Positive rounding down -- 3.2, 12.1, 99.00001  Negative rounding down -- -3.6, -313.9, -334.51  Negative rounding up -- -3.1, -313.001, -334.49  Whole numbers -- 6, -4, 0

9. Begin to Develop Algorithm Much easier to start on paper  Easier to write, test, and fix Break problem up into smaller steps  Each step need not be easy or obvious  Break up test cases to create tests for these steps  Do not worry solving subproblems yet Use test cases to verify algorithm works  If it does not, go back and fix those problems

10. Solving Subproblems Solve each subproblem separately  Do not worry about larger problem or issues  Can break up into even smaller subproblems  Worry about code only when it is obvious Solving problems in any part of life  Solving large problems is hard  Solving small problems is not

11. Combining Subproblems Start coding solution  Code each subproblem separately  Add comments describing what each section does Add printfs everywhere  Use to testing code immediately after writing  First, test only the code just written  Then, test larger subproblem solution  Lastly, test the entire program

12. Combining Subproblems Repeat tests with each new section of code  Errors will be caught immediately  Limits region that may contain the error Compare region with design to spot errors  Add more printfs and compare against traces  Should given good idea of where error occurs  If uncertain, trace code to discover why problem occurs

13. More Debugging Hints Liberally print out value of variables  Give printf unique prefixes to identify them printf(“Hi! %d %c\n”, result, ch); printf(“Yo! %d %c\n”, result, ch); printf(“Whoa! %d %c\n”, result, ch); Once testing done, comment out printfs  Makes it easier if more testing needed later Keep copy of last working version  When in doubt, compare new version against old one

14. Your Turn Get into groups and complete daily activity

15. Midterm Overview Midterm results were very mixed  Max score = 91  Mean score = 83  Standard deviation = 6.18 May apply curve at end of term  Will not curve any single item Can ask me questions next week  Check web page for answers  Everyone still doing well

16. For Next Lecture Complete week #6 weekly assignment Enjoy the respite  Normal workload resumes next week…