Software Design
Fall 2004

For lab:

1) prepare for a warmup that will probably involve writing
   1-2 fruitful functions

For Monday:

1) read Section 6.1, 6.2, and Chapter 7 of "How to think..."


Koch curve
----------

In-class exercise.


Function calls
--------------

1) the mechanical view of a function call:

  a) locate the appropriate function object

  b) evaluate the arguments (which are expressions)

  c) create a frame for the function

  d) assign the values of the arguments to the parameters

  e) execute the body of the function

  f) compute and save the return value

  g) destroy the frame

  h) return to the call site

  i) replace the original function call with the return value


Notes:

  a) don't confuse the function object with a frame

     there is only one function object, created when the
     function is defined; there can be many frames for a
     function, created whenever the function is invoked

  b) remember that arguments are expressions and parameters
     are variables

  c) remember that frames contain parameters and local variables

  d) the return value has no name


2) the abstract view of a function

   a function is a black box that takes values as inputs
   and produces a value as a result

   fruitful functions yield a return value

   void functions usually have an effect (like moving a turtle,
   or drawing something), but don't yield a result


Fruitfulness and voidness
-------------------------

1) fruitful functions are used as expressions:

   itd = distance(t1.x-t2.x, t1.y-t2.y)
   c2 = cos(turtle.heading)**2
   return sqrt(dx**2 + dy**2)

2) void functions are used as statements:

   fd(bob, 90)
   snowflake()
   

Debugging Strategies
--------------------

What do you do when something doesn't work?

First, make sure that you are really running the program you
think you are running!

What you do next depends on what kind of error it is:

Syntax error strategies:

1)

2)

3)


Runtime error strategies:

1)

2)

3)


Logical error strategies:

1)

2)

3)



Appendix A is my attempt to write down what I know about debugging.
Check it out.

General principles of debugging:

1) Make the flow of execution visible.

2) Make program state visible (at the appropriate level of abstraction).

3) Build debugging infrastructure as part of the code.

4) Remove scaffolding only when you are sure you won't need it.

5) Don't get bogged down in one mode:

   a) examine the code

   b) collect data

   c) think about the data you have