Multiple AutoLisp codes(programs) in single lisp file... is that unprofessional way to write an Autolisp file?

[Anonymous]

I used to write multiple lisp programs in a single Auto lisp file for my convenience. I coded the file to show list of programs available in this file in command window.

one of my administrator looked at the way it was created and commented as it is not a professional way to keep multiple lisp programs in a single file. He adds more lisp codes will occupy the memory and will affect AutoCAD performance.

i don't think loading many lisp programs in to a drawing file will cause memory issue. The AutoCAD deals with complex ARX codes and lisps (got this while referring support files). The user customized lisps are not going to affect unless we keep unclosed loops or Auto LISP reactors which checks users command whatever they use. Please advise, keeping multiple Auto lisp programs in a single file is a professional way or not.

[devitg]

@Anonymous If it work, do not fix .

What could be consider professional way. ?

Once I listen:  if a thing  works, it is very well. And for tastes , foods, beverages, and so on . 

Ass far as I know, memory facts, do not count. 

[pbejse]

---

@Anonymous wrote:

...one of my administrator looked at the way it was created and commented as it is not a professional way to keep multiple lisp programs in a single file. He adds more lisp codes will occupy the memory and will affect AutoCAD performance.

---

A young lady went into a diner... [ refer to attachment ]

[Kent1Cooper]

I don't think it's "unprofessional," but consider whether you find it easier to manage them in one collective file, as compared to separate ones, which could have the advantage that they can be named for what they're about, perhaps making it easier to find one when you want to edit its definition.  Another possible advantage is that if a separate-command file gets corrupted or accidentally deleted, you lose only that command, not all of them if a collective file goes bad or is lost.

BUT  I suggest you look into the (autoload) function.  It takes note of  the command names defined in a file, but it doesn't actually load the file unless and until one of those commands is called for.

(autoload "CollectiveLispFile" '("Command1" "Command2" "CommandA" "CommandB"))

[You don't need to include the .lsp at the end of the file name.]

Put that into acaddoc.lsp, and every drawing will be ready to invoke any of those commands.  If none of the commands in it is ever called for, it spares you whatever memory capacity it takes to have it loaded, and the time to load it.

I think I would  omit the long list of command name cues.  With a lot of them like that, a User isn't going to remember all of them once that has scrolled out of sight, so they'd be better off with a paper list, or just remembering the names of commands they use often.

[Sea-Haven]

Agree with Kent use Autoload, but for me I have 1 library lisp that is loaded on startup it has all the autoload definitions in it, as well as library functions rtd etc so don't edit acaddoc.

[diagodose2009]

Eg.1==The library "pp_conjuctura.zip" contain two-main-programs  

              { a)pp_kalandipaital1.lsp + b)pp_conjuctura.lsp }

Eg.2 The library "cadlisp_level1.zip" contain 200'programs  (wcmatch "pp*.lsp"),

  and 1782'functions lisp.

(Warning  "these libraries are obsolute's")

[dgorsman]

Used to be, the way of doing things was to write each function in its own LISP file.  Things were pretty simple at that time.  A 'program' (might not be the best term here) that consists of multiple functions would have all of those functions in a single file, and would be reloaded each time it's used.  LISP programming was well behind the curve of other languages in terms of consistency and organization, so reloading was seen as 'the safe thing to do' to avoid conflicts with non-localized variable names and re-used function/command names.

Things are (well, *should* be) different today.  A lot more traditional software development is being applied to LISP development.  More awareness of localizing variables; verbose command naming; better code documentation; and other good practices are much more common.  This allows for much more complicated, but still highly functional, LISP programming.  Memory is almost a non-issue except for potentially some bad data management practices.

For example, I have a series of library files each contain related LISP functions.  The math library contains all the matrix and vector math functions in one file; it gets loaded at startup so that I don't have the same function (e.g. vector cross-multiplication) defined in multiple different files.  Much like an XREF, it's "Define once, reference where needed".

[john.uhden]

Back before autoload I created my own kind of autoload.  Loading everything for which you will need only a small portion does burn up time which can collectively add up, but the convenience of one VLX is probably worth it.  Besides, the users won't notice any delays while they have switched to their Solitaire game anyway.

Also consider that much of what we write uses the same home-made functions over and over which we have the habit of declaring local.  Why eat up memory loading them multiple times?  And if you want to improve any of your little functions, you need do it only once and recompile.

[Sea-Haven]

I have gone to my Multi inputs as much as possible rather multiple get int real etc its as you say a Library function so consistency in the software look and feel. A multi line dcl input is 1 line of code.

[hak_vz]

I agree with @dgorsman and @Kent1Cooper . Using a lisp file containing a lots of functions is not an issue if code is well written.