1. Design - programming Cmpe 450 Fall 2008

2. Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors introduced in coding Dynamic techniques Executing program and observe its behaviour

3. Static Analysis Ensure quality before execution Design evaluation Code analysis Manual reviews, tools

4. Dynamic Techniques Rush through specs and designs Fix up later Design and implementation mixed, hard to find errors Cost of fixing an error is higher at later stages

5. Static Techniques All errors can not be caught statistically “testing can reveal the presence of errors but never their absence”

6. Defensive Programming To increase reliability of the program by inserting redundant checks Invariants Runtime assertions Testing invariants explicitly

7. Defensive Programming To make code bug free in the most effective way. Always better to write a good code from scratch than fixing a bad code When to write runtime assertions? As you write the code, not later...

8. Runtime Assertions- guidelines Check the precondition at the start of the procedure No room for misunderstandings about interfaces between procedures Check the postcondition Self check Write assertions when operation is about to be performed that has some external effect

9. Runtime assertions- mistakes Runtime assertions slow execution down Write them in testing and turn them off in the official release? WRONG WRONG PRACTICE

10. Debugging

11. Debugging is the least predictable software development activity. One usually doesn’t know in advance whether finding the next bug will take five minutes or five weeks. Some people debug using their intuition. From the nature of the symptom, they can go directly to the parts of the program that are most likely to contain the error. While such intuition is useful and can be developed if you learn from experience, it is not necessary; there is a general approach to debugging that does not need it.

12. General Approach When you run a buggy program on some test data, initially everything is all right (variables have the right values, the right output is produced, control takes the expected path). Things go wrong after a point in time at which a buggy statement is executed. One can identify the buggy statement by identifying this point in time. This of course requires the programmer to be able to tell what the right values of variables are at every point in the program. For programmers other than the original authors, and sometimes even for them, this requires documentation of what the code is meant to do. If this is missing, it has to be recreated.

13. The suspect period The suspect period is initially the entire run, the whole sequence of statements executed by the program. At some point in the middle of the run, you can check whether everything is all right. If not, you can eliminate the part of the suspect period after the point; the first bug is before that point. There may also be bugs after that point, but you should look for them after the first bug is fixed. If yes, you can eliminate the part of the suspect period before the point; the first bug detectable by this test case is after that point. Any bugs before that point need another test case.

14. Binary Search

15. Approximating binary search

16. Minimizing the failed test case

17. Diagnostic printfs

19. Debuggers

20. Forward Execution

21. Choosing breakpoints

22. Breakpoints on functions

23. Global variables

24. Tracking errors to their source

25. Core files

26. Wild pointer errors

27. Laws of debugging

28. Some possibly untrue assumptions

29. Fixing bugs

30. Type safety

31. The magical number seven

32. Coping with complexity

33. Abstraction

34. Modules

35. Undersanding modular programs

36. Information hiding

37. Language support

38. Declaration vs definition

41. Type safety convention, part 1

42. Quiz Is there type safety in C? Explain yes or no on the sample piece of code. What is the problem with this code?

43. Example

45. C’s lack of type safety

46. The problem