Reusable code that you reuse again and again...

[David Kozina]

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:

What I do these days is set local variables within a
command defun if there is necessity to repeatedly
access said objects, and then pass said objects to
functions as required ...

(defun c:SomeCommand ( / application document modespace paperspace )

(setq
application (vlax-get-acad-object)
document (vlax-get-property application 'ActiveDocument) modelspace (vlax-get-property document 'ModelSpace) paperspace (vlax-get-property document 'PaperSpace)
)

(FunctionRequiringApplication application)

(FunctionRequiringDocument document)

(FunctionRequiringModelSpace ModelSpace)

(FunctionRequiringPaperSpace paperspace)

; etc.

(princ)

)

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

 

[David Doane]

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.

 

[TCEBob]

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

 

[ECCAD]

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

 

[Tom Smith]

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.