English subtitles

← First Steps - Software Debugging

Get Embed Code
4 Languages

Showing Revision 4 created 05/25/2016 by Udacity Robot.

  1. Assume you have this big, big program with no runtime checks at all
  2. and you suppose to do the debugging.
  3. Where in that program should you start?
  4. I would suggest the first thing to do is to define data invariants.
  5. This will immediately cover large parts of the program state and catch lots and lots of defects.
  6. The next thing is to provide preconditions which check the data invariants, of course,
  7. but which also check specific preconditions for the functions at hand.
  8. Finally, provide post condition in any method you find suspect.
  9. Start with the partial conditions and then you expand them further and further
  10. to capture more and more of the correct behavior.
  11. Why do we start with data invariants in preconditions?
  12. Well, because they usually way easier to write, catch lots of bugs,
  13. and because we only care about whether a method works or not
  14. if it actually gets the correct argument and gets a correct state to begin with.
  15. On top of that, if you are using C or C++, run a system invariant check up.
  16. You should run the system invariant check up for the simple reason
  17. that it will check for all sorts of memory corruption,
  18. and if your program does have any issues with memory corruption,
  19. then all of these other assertions are totally nulled because they will come up with random results.
  20. Running a tool like Valgrind can detect lots and lots of memory issues
  21. and all it takes is to run your program once, with Valgrind enabled.
  22. A colleague of mine recently transfer from academia to an oil and gas company
  23. and he was in charge of testing.
  24. He introduced the first assertion ever in their code
  25. and immediately, this one single assertion, uncovered dozens of bugs.
  26. The engineers were amazed.
  27. They have never seen anything like this before and this is an experience.
  28. Well, I'm not exactly sure whether you should have that experience too,
  29. but if you come along with code that has no assertion at all,
  30. start adding some and you will be surprised.
  31. Why should we start with data invariants? This is a quiz.
  32. First option, they cover much of the state. Second option, they are frequently checked.
  33. They form implicit pre- and post conditions
  34. because data invariants should hold at the beginning and at the end of each public method.
  35. Final option, they provide helpful documentation
  36. because they document exactly how the data structure is organized
  37. in which assumptions programers should not violate.
  38. Check all that apply. Over to you.