Reusable code that you reuse again and again...

Have you encounted many cases where one section of one routine happened to
be written *exactly* like another section in *another* routine?

Now, I'm NOT talking about repetitive use of 'toolbox' routines that you may
use in your code that use differing parameters, like this:

;...
(myfunction a b c)
;...
(myfunction d e f)
;...

....because they aren't used with *exactly* the same arguments - see?


I can think of one good example that Michael Puckett illustrated a few days
ago:

In this case, that initial (setq... code block that stores the different
objects used later could easily find a spot in many different routines, no?

Can you think of other (perhaps larger) cases wherein this sort of 'code
recycling' would prove beneficial or desirable? I'd appreciate some
additional ideas.

Thanks,
David Kozina

 

Yes. However I never have organized them so as to call them from multiple
routines. I do call one dialog box from several routines though.

 

I think it depends on what your target audience is. I have a library of
routines that I use frequently and for a while was cleverly doing just
as you suggest. And it worked. But then I tried to send one or another
routine to a friend or post it on a ng. Of course, the durn thing
wouldn't work because half the stuff was undefined. So I had to comb
through the code and package all the relevant subs. Now I've gone
through and patched in all the subroutines where they apply and got rid
of them. Well, almost all. Conclusion: if you are writing a long program
or if your application is going out for distribution then subroutines
are really useful. But for the average macro maven (me) they only save a
few lines of code. However, I'm not shy about cribbing lines from one
routine to another.

rs

 

I like to stash text routines (trim, search/replace, etc) away for use, but suffer with same problem when posting. Alas.
Bob

 

I keep a few very general "toolbox" routines in my mnl so they're always
available -- error handler, etc. In a case like you describe, if I find
myself doing the exact same thing in more than a couple of lisp programs,
I'd probably add it to the "toolbox" and take it out of the individual lisp
routine.

Part of the original concept of lisp, of course, was to build big programs
from small parts, using modular, recycled functions. In real-world use, this
can be a litttle tricky to maintain, and it can make it more complicated to
swap lisps around on the net, if that's a concern.

I program in a modular fashion anyway, having learned to appreciate the
age-old rule that a function should do only one thing, and should very
rarely be any longer than about a half dozen lines. So my lisp programs will
normally consist of a number of small defuns, with one calling "c:" defun
which runs them. I realize that this is alien and *disturbing* to the linear
BASIC-like programming schema that you usually see in AutoLISP. But it makes
it easy to pull out a "toolbox" routine that I find myself needing again.

Usually, if I find myself using very similar code, it's because the tasks
being performed are similar, and I can "recycle" functions without confusion
simply by putting multiple "c:" defuns in the same lisp program. For
instance, we have one called mirrortools.lsp, which contains every macro
we've found handy for mirroring plans. Several of them call the same
general-purpose functions, which are defined in the same file for clarity.
These don't need to go in the mnl toolbox, since I don't need them anywhere
else.