Steve Smith:
>Take that array of tuples and put a pointer to it in the parm list. And
>voila, you have only three parms, although two might be enough. The array
>entries can be defined much more flexibly than trying to cram the
>information into a list of addresses
Sure, you could do that-but that's harder for folks to code, because now
they have to understand a structure, and need a header file, COPYBOOK, or
whatever for it, and have to embed that, etc. They still have to build the
tuples *somewhere*; now they can't see them at a glance. Why is that
necessarily better? If it is, why does any function take more than one
argument? Everything should use a structure!
Seriously, I'm chary of doing something just to fit some arbitrary rule like
"more than n arguments is bad". This reminds me of the "GOTOs are bad": yes,
they often are, but there are plenty of cases where a simple GOTO makes the
code MUCH simpler. Taking it back to Rexx, use of SIGNAL for error handlers
is such a case. I'm sure this will set off a bunch of folks, but I maintain
that code like this:
do <somecondition>
if <someothercondition> signal BadWhatever /* Error, go away and don't
come back */
...
end
is often far more readable and maintainable than:
do <somecondition>
if <someothercondition> then do
... /* Handle the error */
end
else do /* The mainline normal path */
...
end
And this is especially true when there are a bunch of such errors. A Rexx
SIGNAL is by definition a "go thee and come back not"; coding as I suggest
allows reading and understanding the mainline, rather than trying to find it
among all the nested IF/ENDs of the error handlers. (It also allows grouping
the errors together, and makes it easier to not issue two
similar-yet-different versions of the same error by accident.) (Rexx makes
this approach easier in that there's usually no need to do any particular
cleanup, so "single entry, single exit" is less critical; however, if all
those common errors wind up themselves SIGNALling to a common error exit
cleanup point, that also works. I also realize that some folks essentially
do what I suggest, but CALL the error handler, with no intention of
returning. That can also be useful, if they're taking advantage of that CALL
to pass arguments; but if they are not, then they're making it harder to
read, because the new person maintaining the code has to look and see
whether that CALL is going to return or not. With a SIGNAL, there's no
question.)
Yet folks say "Oooh, SIGNAL is like GOTO, and GOTO is unequivocally bad, so
I must not use SIGNAL". And this results in fugly, unreadable code.
And yes, this is theology. Hence the Subject: line! A fun discussion, let's
continue.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
