[REBOL] Re: Trace function
From: joel:neely:fedex at: 21-Jun-2001 2:39
[Sanghabum--aol--com] wrote:
> I suspect the lack of response to my request indicates just
> how few of us ever go near Trace after the first encounter.
>
I suspect you're right.
> I'm sure we've all got our
> little toolkit of debugging toys. The simplest one I have is
> in my USER.R....
>
> debugprint: :print
>
> ....so I can search code later for all Print statements that
> exist only for debugging.
>
Not only that, but you can later re-define
debugprint: func [dummy [any-type!]] []
to disable debugging! You've got a good idea there.
> I think it is a shame that Rebol does not have a better set
> of debugging tools.
>
> Perhaps we could open this thread out....Anyone else got
> little scripts or tricks they use for debugging that they'd
> like to share?
>
1) (re)factoring,
2) objects,
3) probe
1) My favorite way to deal with debugging is to avoid it as
much as possible (yeah, right! ;-) by (re)factoring the
code into small, black-box pieces that can be recombined as
flexibly as possible. This includes the use of higher-order
functions such as MAP.
In my experience, I'm much more likely to *need* debugging
tricks with long sprawling functions than with concise ones.
2) Of course, I can get in a hurry and mess up even the most
simple-looking functions. By wrapping a group of related
functions into an object, and using data-like members of that
object as scratch space, I can more easily perform a test and
then look at the after-effects (or even add snapshot members)
to see where I went off the rails.
3) When I keep my individual functions small and orthogonal,
I usually find that a small number of well-placed PROBEs
help me get a function working and tested with less effort.
In a way, I'm glad that TRACE is so unwieldy! I've used other
languages/platforms that had big piles of inspectors, "live"
data displays, breakpoints, etc... While those things may be
hard to against in *some* situations (embedded software,
kernel, and device driver development, for example), I find
that in most programming situations in a reasonable high-level
language, they make it all too easy for me to get sloppy in
my design and coding, because I've got such industrial-strength
automated crutches to fall back on!
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
