Source code organization

[Anonymous]

Never having taken a programming class, let alone having a CS degree.
Everything I know about programming (not a lot) has been self taught through
books, this NG, source code, help files, etc.

I have about 200 or so different LSP files that I maintain. Most of them
have been completely hands off for years, but I have had to go into and
edit/update/modify a good chunk of. Either by creating new ones, improving
the most used routines, fixing bugs, what have you.

My question to the group is this. What kind of source code organization do
you gurus have? File/directory structure, grouping of functions by task,
stuff like that and what ever else you can think of.

--
Kevin Nehls

[Anonymous]

Kevin,
That's a whopper of a topic.
I guess it depends on
1. Are your tasks simple or complex?
2. Are you selling modules or using all the stuff yourself?
3a. Do you need a revision history?
3b. Might you need to revert to a previous version?
.......
First step I took was to identify the places where I spent a lot
of time with code that didn't do anything but avoid bad side-effects
and improve user I/O. I made standard functions for those so
that simplfied all my other programs.

I use all my stuff so I keep it in just a couple of folders to
simplify use(ACAD path simplicity).

When debugging, I use version naming. When the new version
works perfectly then I copy the old version with a number and
then remove the version number from the replacement.

Doug


"Kevin Nehls" wrote in message news:[email protected]...
> Never having taken a programming class, let alone having a CS degree.
> Everything I know about programming (not a lot) has been self taught through
> books, this NG, source code, help files, etc.
>
> I have about 200 or so different LSP files that I maintain. Most of them
> have been completely hands off for years, but I have had to go into and
> edit/update/modify a good chunk of. Either by creating new ones, improving
> the most used routines, fixing bugs, what have you.
>
> My question to the group is this. What kind of source code organization do
> you gurus have? File/directory structure, grouping of functions by task,
> stuff like that and what ever else you can think of.
>
> --
> Kevin Nehls
>
>
>
>

[Anonymous]

I'm with Doug here, that is a whopper of a topic. As far as directory
structure goes this is what I have done so far with the stuff I have setup
for my company, works pretty good for what we do and helps me keep it all
organized. It may seem like overkill to some to have all of the separate
folders for each 'type' of routine but, it makes everything much easier to
find (especially at the rate my files are increasing these days. 🙂

Support <- Company Menu Files
Arx
Images <- Toolbar images (untill I compile to .dll)
Lisp
Annotations
Blocks
Concrete
Dimension
Layers
Layouts
Steel
Working <- started and never finished (bunch in there)
From Net <-Stuff picked up on the NG's until I can process it all
Master Lisp Tools
AttTools.lsp
AxBlockTools.lsp
AxLayoutTools.lsp
BlockTools.lsp
DicTools.lsp
Dimension Tools.lsp
GeneralTools.lsp
GroupTools.lsp
LayerTools.lsp
LayoutTools.lsp
LineTypeTools.lsp
LwPolyTools.lsp
PageSetupTools.lsp
SelectionSetTools.lsp
StringTools.lsp
TableTools.lsp
TextStyleTools.lsp
TextTools.lsp
TrigTools.lsp
ViewportTools.lsp

I have all of the files in my 'Master Lisp Tools' folder loaded on startup,
so I have access to any of my *master* functions at any time. For a while
in my routines I was testing for a master function being loaded if not, then
load it etc... that got real old, real quick so I just figured why not just
load it all and forget about it.

I try to keep a small header with each function, describing what it does and
give an example if it isn't blatantly obvious what the function does. I
haven't ever needed an older version of a function yet, so I don't worry
about saving different versions. Having all of the separate folders it does
add a few to Acad's search path but if the worst of it is adding search
paths, I'm happy.

Hope this helps.

--
-Jason

Member of the Autodesk Discussion Forum Moderator Program


> What kind of source code organization do
> you gurus have? File/directory structure, grouping of functions by task,
> stuff like that and what ever else you can think of.

[Anonymous]

We have it setup this way:

S:\Aquatic Desktop 3.0
BatchPlot (pc3 files for use with our batchplot program)
Support (menus, drawings, fonts and anything else that I need in the
autocad support path)\
Programs (lisp files)
Setup (intallation files)

The only path that gets added the acad support path is the support
directory. I have a program that sets a key in the registry to the string
"S:\Aquatic Desktop 3.0". I then set a global variable (aq*GetPath) that
contains the value from the registry. So instead of hard coding the path I
just do this if I need something in a directory other than the support
directory:
(strcat aq*GetPath "\\tblocks\\imperial\\a-concpt-i.dwg")

This makes the code very portable and does not lock it down to a specific
drive or path.

Hope that made sense....

--
Joel Roderick
Water Technology, Inc.
www.watertechnologyinc.com

[Anonymous]

(not a guru here either)
Big topic and one that I've thought about and changed from time to time in
how I do it.

I have a couple of folders, One called Apps. This is where the "finished"
stable routines are places usually as FAS or VLX. Then I have a Lisps
folder where I keep the source code. This is off limits to others in case
someone one improve somthing. I work on stuff here until I think it's in
its almost final form, then I edit the acaddoc.lsp and have my machine load
those lsp file overriding the previous version and I put it through its
paces for a week or so until I am sure the bugs are out and nothing is
goofy. Then I compile it and place it in the Apps folder for everyone to
use. I generally don't keep much of the old stuff but I do try to keep a
copy of some things in the event that I really screwed up and need to go
back.

I load the absolutes everytime and autoload everything else to reduce start
up time.

I break the lisp functions into different files which contain similar
functions, ie. dims, text, leader, keynotes, error handler, common
functions, page setup, elevation tags, detail tags, drafting tools, symbols,
dwg setup, etc. Everything gets a version number at the end - sa_page4.lsp.
Meaning I'm on my fourth version of the total program suite. No necessarily
on an actual fourth version of that file. The suite version gets updated
with the autocad/adt release. Not much may change between versions but it's
a way to let me know I've actually worked this thing out for the particular
acad/adt version. Case in point I am still using version 3 of our keynotes
routine and am still working on version 4. In appearance nothing much
really changed between the two and version 3 was editted to work with the
current version of adt but there were some ineffeciencies or changes in code
that I wanted to do it improve updating it for the next release and to
better add features.

CJ Follmer


"Kevin Nehls" wrote in message
news:[email protected]...
> Never having taken a programming class, let alone having a CS degree.
> Everything I know about programming (not a lot) has been self taught
through
> books, this NG, source code, help files, etc.
>
> I have about 200 or so different LSP files that I maintain. Most of them
> have been completely hands off for years, but I have had to go into and
> edit/update/modify a good chunk of. Either by creating new ones,
improving
> the most used routines, fixing bugs, what have you.
>
> My question to the group is this. What kind of source code organization
do
> you gurus have? File/directory structure, grouping of functions by task,
> stuff like that and what ever else you can think of.
>
> --
> Kevin Nehls
>
>
>
>

[Anonymous]

This is all really good info. I don't really need to check the old version,
I just usually keep them around a couple of weeks incase a new version
introduces a major bug I didn't find. This way I can go back to the
previous version and work the bug out without everyone having to wait on
that getting fixed.

Some tasks are simple, some are complex and some are trying to make the
complex ones simple. For instance, I'm updating our "notes" routine to read
from a text file instead of inserting each note from a block. Maintaining
60+ dwg files for the different notes is a pain, but 1 text file is nice and
easy.

We're not selling any of this code. It's all just for company use.

Here's our setup.

Everyone has 1 local directory (by default) C:\acadmech, which is listed at
the top of the support paths. They can put anything in here they want and
that I don't want on the server.

On the server (it's actually a pretty flat structure)
I:\Acad Files <- contains files installed by autocad, but customized by us
I:\Dev\Src <- contains the source code of all LSP files
I:\Dev\Update <- this is where I planned to work on updates and new
routines, but it usually ends up happening on my local system.
I:\Fonts <- duh
I:\SW Support <- Contains all "standard" compiled lsp files, menu files and
all "standard" blocks, there are a few sub-dirs of some specialty blocks,
but that's it.

The overall file structure is pretty flat. I want to organize it into
categories so that if I ever left, someone new could take a look at it and
any readme.txt files I have and get a pretty good understanding of what's
going on. I also need to go through all of the routines to add some
description to them. I inherited most of what's going on here and have
re-worked some of it. It was a real pain when I first started with it, but
after 4+ years I now know where everything and mostly how it works.

--
Kevin Nehls

[Anonymous]

I guess that's the lesson. Don't worry about how you organize it some much
but document it so someone else can figuire out your sceme and what you were
doing.

CJ

"Kevin Nehls" wrote in message
news:[email protected]...
> This is all really good info. I don't really need to check the old
version,
> I just usually keep them around a couple of weeks incase a new version
> introduces a major bug I didn't find. This way I can go back to the
> previous version and work the bug out without everyone having to wait on
> that getting fixed.
>
> Some tasks are simple, some are complex and some are trying to make the
> complex ones simple. For instance, I'm updating our "notes" routine to
read
> from a text file instead of inserting each note from a block. Maintaining
> 60+ dwg files for the different notes is a pain, but 1 text file is nice
and
> easy.
>
> We're not selling any of this code. It's all just for company use.
>
> Here's our setup.
>
> Everyone has 1 local directory (by default) C:\acadmech, which is listed
at
> the top of the support paths. They can put anything in here they want and
> that I don't want on the server.
>
> On the server (it's actually a pretty flat structure)
> I:\Acad Files <- contains files installed by autocad, but customized by
us
> I:\Dev\Src <- contains the source code of all LSP files
> I:\Dev\Update <- this is where I planned to work on updates and new
> routines, but it usually ends up happening on my local system.
> I:\Fonts <- duh
> I:\SW Support <- Contains all "standard" compiled lsp files, menu files
and
> all "standard" blocks, there are a few sub-dirs of some specialty blocks,
> but that's it.
>
> The overall file structure is pretty flat. I want to organize it into
> categories so that if I ever left, someone new could take a look at it and
> any readme.txt files I have and get a pretty good understanding of what's
> going on. I also need to go through all of the routines to add some
> description to them. I inherited most of what's going on here and have
> re-worked some of it. It was a real pain when I first started with it,
but
> after 4+ years I now know where everything and mostly how it works.
>
> --
> Kevin Nehls
>
>

[Anonymous]

Yea I guess that's the main part of it. Thanks for the info guys.
Sometimes you just need to talk it out in the open to get a better grasp of
things.

--
Kevin Nehls


"CJ Follmer" wrote in message
news:[email protected]...
> I guess that's the lesson. Don't worry about how you organize it some
much
> but document it so someone else can figuire out your sceme and what you
were
> doing.
>
> CJ

[Anonymous]

As far as headers go, I settled on this awhile ago (see attached).

My folder structure on the network is fairly flat also, with Toolbox
routines stored in a folder under the "Program" folder.

I do all development on my local drive (with frequent backups!) and AutoCAD,
on my laptop, uses these development folders as the primary support path.

I also make sure that all toolbox functions have a unique prefix to help me
identify them (rrbI:).

--
R. Robert Bell, MCSE
www.AcadX.com


"Kevin Nehls" wrote in message
news:[email protected]...
> This is all really good info. I don't really need to check the old
version,
> I just usually keep them around a couple of weeks incase a new version
> introduces a major bug I didn't find. This way I can go back to the
> previous version and work the bug out without everyone having to wait on
> that getting fixed.
>
> Some tasks are simple, some are complex and some are trying to make the
> complex ones simple. For instance, I'm updating our "notes" routine to
read
> from a text file instead of inserting each note from a block. Maintaining
> 60+ dwg files for the different notes is a pain, but 1 text file is nice
and
> easy.
>
> We're not selling any of this code. It's all just for company use.
>
> Here's our setup.
>
> Everyone has 1 local directory (by default) C:\acadmech, which is listed
at
> the top of the support paths. They can put anything in here they want and
> that I don't want on the server.
>
> On the server (it's actually a pretty flat structure)
> I:\Acad Files <- contains files installed by autocad, but customized by
us
> I:\Dev\Src <- contains the source code of all LSP files
> I:\Dev\Update <- this is where I planned to work on updates and new
> routines, but it usually ends up happening on my local system.
> I:\Fonts <- duh
> I:\SW Support <- Contains all "standard" compiled lsp files, menu files
and
> all "standard" blocks, there are a few sub-dirs of some specialty blocks,
> but that's it.
>
> The overall file structure is pretty flat. I want to organize it into
> categories so that if I ever left, someone new could take a look at it and
> any readme.txt files I have and get a pretty good understanding of what's
> going on. I also need to go through all of the routines to add some
> description to them. I inherited most of what's going on here and have
> re-worked some of it. It was a real pain when I first started with it,
but
> after 4+ years I now know where everything and mostly how it works.
>
> --
> Kevin Nehls
>
>

[Anonymous]

Very nice. I'm glad to see you update the version just for me ;). Mind if
I adopt the general layout?

One quick question about your header. Where you list the dependencies, do
you just list external functions or the actual LSP file, or are these one in
the same? I have done this with some of my newer routines as well as
prefixing the routines.

Also, how do you handle more than one function definition within a single
LSP file? I generally have 1 LSP file for a "program" that has several
"support" functions for that routine defined within it. Is this wise or
should one put each of those in separate LSP files then compile the entire
program into one VLX file?

Your great wisdom is much appreciated.

--
Kevin Nehls


"R. Robert Bell" wrote in message
news:[email protected]...
> As far as headers go, I settled on this awhile ago (see attached).
>
> My folder structure on the network is fairly flat also, with Toolbox
> routines stored in a folder under the "Program" folder.

[Anonymous]

Adopt all you want! 😉

I list each dependency by function. All my functions are handled by an
autoloader, so the source filename isn't that important to me (and less
typing that way!). Some functions are wrapped into one lisp file, others are
single function/single file, so the autoloader is where I would look if I
can't remember.

As far as applications go, some subrs are "one-shot" so they are in the main
application lisp file, others are definitely "toolbox" material, and are
separate.

Glad to give you my take on it... 😉


--
R. Robert Bell, MCSE
www.AcadX.com


"Kevin Nehls" wrote in message
news:[email protected]...
> Very nice. I'm glad to see you update the version just for me ;). Mind
if
> I adopt the general layout?
>
> One quick question about your header. Where you list the dependencies, do
> you just list external functions or the actual LSP file, or are these one
in
> the same? I have done this with some of my newer routines as well as
> prefixing the routines.
>
> Also, how do you handle more than one function definition within a single
> LSP file? I generally have 1 LSP file for a "program" that has several
> "support" functions for that routine defined within it. Is this wise or
> should one put each of those in separate LSP files then compile the entire
> program into one VLX file?
>
> Your great wisdom is much appreciated.
>
> --
> Kevin Nehls
>
>
> "R. Robert Bell" wrote in message
> news:[email protected]...
> > As far as headers go, I settled on this awhile ago (see attached).
> >
> > My folder structure on the network is fairly flat also, with Toolbox
> > routines stored in a folder under the "Program" folder.
>
>

[Anonymous]

>
> I do all development on my local drive (with frequent backups!) and AutoCAD,
> on my laptop, uses these development folders as the primary support path.
>

To reinforce this, I had a disk crash last week and was not sweating too badly since
I back up with laplink to my laptop each day. It still took 12-14 hours after the
time to run 3 scandisks, buy and install a new drive and make a disk copy. The
computer was only 2 years old. That makes my 3rd hard disk crash in 12 years.

Backups are vital!

----------

I saw that Jason was grouping functions into lisp files. I keep most of them separate
(except for primary header - library) and add autoload commands for each. So only
the functions I use are loaded. His grouping seems like a good idea if you were to
sell and maintain packages as a whole.

Doug

[Anonymous]

I have a question about the "toolbox" material. I have a few routines that
I have gotten here and other places that I use in my routine(programs) All I
do is copy paste them into the main lisp. Is this not good practice should
I call those routines as needed? It is funny this thread comes up because I
am doing some "spring cleaning" and am doing the same thing as far as
organizing routines and creating file structure for that. It must be in the
air.
Second question on the toolbox routines I always give the credit were it is
due, I REM out a line to give props to the mastermind that again brings me
to my question. If I use these routines in a bigger program I would have to
give a copy of the called routine out as well that is the reason I cut and
paste into 1 file. Good, Bad?
--
Timothy Spangler
Product Manager
Rasche Brothers Inc.

"R. Robert Bell" wrote in message
news:[email protected]...
> Adopt all you want! 😉
>
> I list each dependency by function. All my functions are handled by an
> autoloader, so the source filename isn't that important to me (and less
> typing that way!). Some functions are wrapped into one lisp file, others
are
> single function/single file, so the autoloader is where I would look if I
> can't remember.
>
> As far as applications go, some subrs are "one-shot" so they are in the
main
> application lisp file, others are definitely "toolbox" material, and are
> separate.
>
> Glad to give you my take on it... 😉
>
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com
>
>
> "Kevin Nehls" wrote in message
> news:[email protected]...
> > Very nice. I'm glad to see you update the version just for me ;). Mind
> if
> > I adopt the general layout?
> >
> > One quick question about your header. Where you list the dependencies,
do
> > you just list external functions or the actual LSP file, or are these
one
> in
> > the same? I have done this with some of my newer routines as well as
> > prefixing the routines.
> >
> > Also, how do you handle more than one function definition within a
single
> > LSP file? I generally have 1 LSP file for a "program" that has several
> > "support" functions for that routine defined within it. Is this wise or
> > should one put each of those in separate LSP files then compile the
entire
> > program into one VLX file?
> >
> > Your great wisdom is much appreciated.
> >
> > --
> > Kevin Nehls
> >
> >
> > "R. Robert Bell" wrote in message
> > news:[email protected]...
> > > As far as headers go, I settled on this awhile ago (see attached).
> > >
> > > My folder structure on the network is fairly flat also, with Toolbox
> > > routines stored in a folder under the "Program" folder.
> >
> >
>
>

[Anonymous]

Call as needed. What happens if you want to do an update on a frequently
used function? Have fun modifying it in a bunch of places... 😉

True, on your 2nd point (if the toolbox files are separate). But VLIDE's
projects make that process easy to handle.

--
R. Robert Bell, MCSE
www.AcadX.com


"Timothy Spangler" wrote in message
news:[email protected]...
> I have a question about the "toolbox" material. I have a few routines
that
> I have gotten here and other places that I use in my routine(programs) All
I
> do is copy paste them into the main lisp. Is this not good practice
should
> I call those routines as needed? It is funny this thread comes up because
I
> am doing some "spring cleaning" and am doing the same thing as far as
> organizing routines and creating file structure for that. It must be in
the
> air.
> Second question on the toolbox routines I always give the credit were it
is
> due, I REM out a line to give props to the mastermind that again brings me
> to my question. If I use these routines in a bigger program I would have
to
> give a copy of the called routine out as well that is the reason I cut and
> paste into 1 file. Good, Bad?
> --
> Timothy Spangler
> Product Manager
> Rasche Brothers Inc.
>

[Anonymous]

This is where I've been thinking of breaking out the lower level functions
like my string related functions into a separate directory in my source
tree. I can work on each function in their own LSP file with it's own
comments, then use VLIDE's project functions to compile them into a single
VLX file and placing that file into my support directory.

--
Kevin Nehls


"R. Robert Bell" wrote in message
news:[email protected]...
> True, on your 2nd point (if the toolbox files are separate). But VLIDE's
> projects make that process easy to handle.
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com

[Anonymous]

I've never been much of a fan of trying to categorize functions... sometimes
they cross boundaries, and then what?! Not to mention that you could go
"click-crazy" trying to work in that sort of folder structure.

--
R. Robert Bell, MCSE
www.AcadX.com


"Kevin Nehls" wrote in message
news:[email protected]...
> This is where I've been thinking of breaking out the lower level functions
> like my string related functions into a separate directory in my source
> tree. I can work on each function in their own LSP file with it's own
> comments, then use VLIDE's project functions to compile them into a single
> VLX file and placing that file into my support directory.
>
> --
> Kevin Nehls
>
>
> "R. Robert Bell" wrote in message
> news:[email protected]...
> > True, on your 2nd point (if the toolbox files are separate). But VLIDE's
> > projects make that process easy to handle.
> >
> > --
> > R. Robert Bell, MCSE
> > www.AcadX.com
>
>
>

[Anonymous]

Well this is exactly what I'm trying to sort out. I don't want to put all
of these routines in my acaddoc.lsp file and I'd like to avoid putting them
in my mnl file(s). I just can't think of where else, or what is the most
logical place, to put low level string/math/number type of functions.

Any ideas/theories/etc are greatly appreciated on this subject.

--
Kevin Nehls


"R. Robert Bell" wrote in message
news:[email protected]...
> I've never been much of a fan of trying to categorize functions...
sometimes
> they cross boundaries, and then what?! Not to mention that you could go
> "click-crazy" trying to work in that sort of folder structure.
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com

[Anonymous]

My other thing is what about changing jobs or using multiple machines, I
want the ability to copy all of MY files out with little trouble. I also
want to keep my functions separate from everything else (ACAD Standard
Files). As Far as the support path thing I just have a lisp that adds all
of the directories I use with my lisp when I need it to. But I still find
it hard to look in 1 or 2 folders of about 100+ routines each to find what I
am looking for. How do you fix that?

--
Timothy Spangler
Product Manager
Rasche Brothers Inc.
"Kevin Nehls" wrote in message
news:[email protected]...
> Well this is exactly what I'm trying to sort out. I don't want to put all
> of these routines in my acaddoc.lsp file and I'd like to avoid putting
them
> in my mnl file(s). I just can't think of where else, or what is the most
> logical place, to put low level string/math/number type of functions.
>
> Any ideas/theories/etc are greatly appreciated on this subject.
>
> --
> Kevin Nehls
>
>
> "R. Robert Bell" wrote in message
> news:[email protected]...
> > I've never been much of a fan of trying to categorize functions...
> sometimes
> > they cross boundaries, and then what?! Not to mention that you could go
> > "click-crazy" trying to work in that sort of folder structure.
> >
> > --
> > R. Robert Bell, MCSE
> > www.AcadX.com
>
>

[Anonymous]

All of our "standard", custom routines, menus, blocks, fonts, pgp, fmp, lin,
pat, arx, etc files are located on a network share. It gets backed up every
night to tape. So going from machine to machine is not a problem. If I
were to change jobs, I'm not sure what I would do. Most of these files are
owned by my company, so I shouldn't take them with me. I know there are
some I would like to take with me, but there are a lot of them that are just
way to specific to how our system is setup that they'd be pretty useless
almost anywhere else.

--
Kevin Nehls


"Timothy Spangler" wrote in message
news:[email protected]...
> My other thing is what about changing jobs or using multiple machines, I
> want the ability to copy all of MY files out with little trouble. I also
> want to keep my functions separate from everything else (ACAD Standard
> Files). As Far as the support path thing I just have a lisp that adds all
> of the directories I use with my lisp when I need it to. But I still find
> it hard to look in 1 or 2 folders of about 100+ routines each to find what
I
> am looking for. How do you fix that?

[Anonymous]

Since I have an autoloader file (Toolbox.lsp) that autoloads *all* my
functions, I don't need to go looking for anything, unless I need to edit a
function...

--
R. Robert Bell, MCSE
www.AcadX.com


"Timothy Spangler" wrote in message
news:[email protected]...
> My other thing is what about changing jobs or using multiple machines, I
> want the ability to copy all of MY files out with little trouble. I also
> want to keep my functions separate from everything else (ACAD Standard
> Files). As Far as the support path thing I just have a lisp that adds all
> of the directories I use with my lisp when I need it to. But I still find
> it hard to look in 1 or 2 folders of about 100+ routines each to find what
I
> am looking for. How do you fix that?
>