IFB104 Lecture Notes - Lecture 11: Defensive Programming, Requirements Elicitation, Runtime System
Document Summary
Topic 11 - how to stop programs crashing. To sol(cid:448)e this p(cid:396)o(cid:271)le(cid:373), (cid:449)e (cid:374)eed to (cid:271)e(cid:272)o(cid:373)e skilled at (cid:862)(cid:396)e(cid:395)ui(cid:396)e(cid:373)e(cid:374)ts eli(cid:272)itatio(cid:374)(cid:863) Some approaches: contractual requirements documents, prototyping/mock ups, agile development methodologies. Debugging your code: careful debugging is the first line of defence against mistakes made by the programmer, merely adding a few calls to the print function to your code may be enough to help you diagnose a bug. I(cid:374) (cid:373)o(cid:396)e (cid:272)o(cid:373)ple(cid:454) situatio(cid:374)s use a tool like idle (cid:859)s de(cid:271)ugge(cid:396) to help t(cid:396)a(cid:272)e variable values. In computer science these are also known as the pre -conditions for correct operation. If an invalid value is received the program may: request another value, use a default value instead. Allow for unexpected values: another defensive programming technique is to anticipate that external input values may not always be 100% accurate, we should allow for slight errors in external inputs, especially when using floating point numbers.
