Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtp47.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!rti-sel!rtp47!throopw
From: throopw@rtp47.UUCP (Wayne Throop)
Newsgroups: net.lang.c
Subject: Re: Program design techniques? (debugging)
Message-ID: <123@rtp47.UUCP>
Date: Sun, 4-Aug-85 13:55:51 EDT
Article-I.D.: rtp47.123
Posted: Sun Aug  4 13:55:51 1985
Date-Received: Tue, 6-Aug-85 08:32:03 EDT
References: <437@spar.UUCP>
Organization: Data General, RTP, NC
Lines: 35

I am a top-down, design-by-refinement advocate.  However, that isn't
what I wanted to post about.  A paragraph in the referenced posting made
me think of a debugging/development technique that is familiar to Lisp
users, but less so to C users.  It might be useful, so I'll describe it.

> This last is fraught with opportunity:  Implementing from the top down can
> produce an interim situation in which you have an elaborate control
> structure or driver which is untestable because it's not hooked to anything
> that does anything; implementing from the bottom up can result in lots of
> little primitives that are untestable because there is no way to coordinate
> their activities cooperatively.

Given a moderately good debugger, you can set breakpoints on stubs, and
"do them by hand", allowing the control structures to be excersized.
For example, say that a stub is supposed to fill in a data structure
from input text, and return the data structure.  If the input routines
aren't fleshed out yet, one can simply write the stub to return a local
data item, and fill it in using the debugger when the breakpoint on that
stub is taken.

The same idea works for bottom-up design, but in reverse.  One can write
a top-level stub which simply calls each of the primitives you are
trying to check out.  The debugger can be used to direct control to each
primitive in the proper order "by hand".

This technique is very usefull when building a prototype, or in testing
a partially completed implementation.  It is what is sometimes refered
to as "debugging a program into existance".  It's main advantage is
that, having tested part of the program, whan an addition breaks what
used to work, one knows where to look for the bug (in the newly added
code).  All existing  code is (fairly well) debugged already.

My appologies if this technique is already well-known, or passe.
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw