I think Bill Fairchild's advice is very good advice because I do
something very similar.
I do, however, take things a step further. I put such code in a
trivial in-line framing macro of the form
| macro
| FRAMETEST &diag=no --|yes
| . . .
|&omit setb ('&diag' eq 'no')
| . . .
| aif (&omit).after_diag1
|<diagnostic code>
|.after_diag1 anop
| . . .
| aif (&omit).after_diag2
|<diagnostic code>
|.after_diag2 anop
| . . .
| mend , --FRAMETEST ends
ete., etc.
My own experience is that if I need diagnostic machinery for the
original version of a routine I shall need much of it again when I
make changes, and this simple scheme permits me to leave diagnostic
machinery in source code innocuously. I have also found that the
certainty that I and perhaps even others will see it over and over
again improves the quality of my diagnostic code.)
I suspect that Bill has other (unmentioned) machinery that largely
automates the implementation of the machinery he did describe, and you
will find it worthwhile to invest in such meta-machinery too.
One of the marks of a professional in this business is that he or she
has a growing and eventually large personal toolkit the contents of
which make like easier for him by eliminating much otherwise
deadening, repetitive work. Assembly-language programming is said to
be long-winded and detail-ridden, but these characteristics can be
much mitigated. (They cannot be entirely eliminated, and it is not
even desirable that they be eliminated, but that is a topic for
another day.)
John Gilmore, Ashland, MA 01721 - USA
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
