[AccessD] FMS Inc. Sourcebook

JWColby jwcolby at colbyconsulting.com
Thu May 3 11:23:40 CDT 2007


Charlotte,

>I think you misunderstand the purpose and use of something like code
librarian.

And Arthur specifically mentioned "cutting and pasting modules into
applications" which was what I was commenting about.  Cutting and pasting
anything into applications indicates that a) you have (probably) used it
before, and b) you are using it again.  Now a) is iffy, but if it is true
then you have reached the point where it should probably be in the library.

>I agree with you about libraries in principle, but when you build something
that works one-off, you stuff the code into Code Librarian as a template in
case you need to do something similar.

Which is of course something completely different and a very good use for
code librarian.

>I don't know about you, but I'm not omniscient enough to know that *this
precise version of a routine* belongs in a library so I can use it over and
over.  I generally wait until the usefulness is clear before I start
building libraries.

Works for me.  If a function is specific to the application, it belongs in
the application.  In general I don't have "versions of functions".

>Also, libraries in Access can be a pain when you have to distribute them,
since they don't compile into a dll.  

Sounds like an excuse to cut and paste.  Is it not a PITA to go find and fix
an error inside of 47 different applications?  Is that easier than copying a
library where it needs to go?  Now what happens when you have 10 bug fixes
or 30?  A library ALWAYS wins!!!

>If your library gets deleted, you are SOL.  

True.  And if your application gets deleted you are SOL.  Sounds like an
excuse to cut and paste.

>And since libraries should be mdes, every time you "update" one, you have
to rebuild it.

I don't have any such belief.  My library is an MDA, as is the application.
If you want to use MDEs then you have to deal with the issues thereof.

The point of a library is "write once, use forever", and "fix once, fix
everywhere".  Cut and paste does NOT meet the second criteria.  Sorry, it
just doesn't.

You can make up excuses to cut and paste till the cows come home.  It is not
my job to follow you around making sure you don't do that, but it is my job
to point out the flaws in the process so that other developers won't go
getting the idea that it is a good practice.  In general it just isn't good
practice.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Thursday, May 03, 2007 11:37 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] FMS Inc. Sourcebook

John,

>I hate to hammer on this over and over, but that is what a library is
for. 

LOL You LOVE to hammer on this!!

I think you misunderstand the purpose and use of something like code
librarian.  I agree with you about libraries in principle, but when you
build something that works one-off, you stuff the code into Code Librarian
as a template in case you need to do something similar.  It's very handy for
reference instead of trolling the internet for hours looking for the right
exanmple.  I don't know about you, but I'm not omniscient enough to know
that *this precise version of a routine* belongs in a library so I can use
it over and over.  I generally wait until the usefulness is clear before I
start building libraries.  Also, libraries in Access can be a pain when you
have to distribute them, since they don't compile into a dll.  If your
library gets deleted, you are SOL.  And since libraries should be mdes,
every time you "update"
one, you have to rebuild it.

Charlotte Foust

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby
Sent: Thursday, May 03, 2007 5:58 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] FMS Inc. Sourcebook

>I like it because then I can stop trying to remember what app I wrote a
given function in. When starting a new app, I usually load CodeLib and then
copy in several standard modules.

I hate to hammer on this over and over, but that is what a library is for. 

Did you know that when Windows XP shipped it had SIXTY THOUSAND known bugs
and (more importantly) an unknown number of unknown bugs.  In order to fix
these bugs what does MS do?  Updates.  What do updates do?
Install a new "library" with bug fixes.  Can you imagine Microsoft having to
rifle through your installation of windows looking for the lines of code
that have a bug that they just fixed and fixing it everywhere on 200 million
computers?  It is a silly concept and we all know that.

I am sure that you are convinced that you have no bugs in your code, but
statistics say 1 in 20 lines of code has a bug.  This can be something gross
such as never ending loop (which we mostly find immediately and
fix) to something subtle like loss of data from a type conversion or
something.  By cutting and pasting your code, you cut and paste your bugs.
NOW you have to remember what apps you cut and pasted bugs into!
A referenced library allows you to fix a bug and simply insert that fixed
library into the project.  Since all your projects use your lib, all your
projects get your bug fixes when you insert a new lib.

I make it a policy that all GENERIC code goes in my library.  All project
specific code goes in the project.  If it is not used anywhere else then it
obviously does not belong in my library, however if it is going to be used
in any other project then it does belong in my library.

Libraries guys, NOT cut and paste modules.

And sorry Arthur, I am not picking on you.  I see LOTS of people talking
about "cutting and pasting" into their projects.  That is simply a no-no in
modern system design.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list