[AccessD] Naming Conventions

Sure, and while I'm at it I'll also try to convince my coworkers to
adopt 2-letter naming conventions.
Better get some sleep this weekend.  I'm gonna have a busy Monday!

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Saturday, August 14, 2004 11:44 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Naming Conventions


>Eventually I stopped doing it mainly for the benefit of others who have

>to
maintain my code.

Yes, but if you could get a significant portion of people to use this
then....

Uhh... Never mind.

;-)

John W. Colby
www.ColbyConsulting.com 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Brett
Barabash
Sent: Saturday, August 14, 2004 12:11 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Naming Conventions


Jim,
Are you sure that Dijkstra actually condemned GOSUB statements?
Practically everyone in the computer science community knows about his
groundbreaking "GOTO statements considered harmful" paper, but I have
never heard this applied to GOSUBs.

In some older BASIC languages, a GOSUB statement was used in a similar
manner to CALL, in that it would execute a separate subroutine, and
return to the exact same point in the calling routine when complete.
This concept is directly in line with the tenets of structured
programming, and IMHO a vital tool for modularizing code into manageable
blocks.  Contrast this with the "evil" GOTO statement, which allowed one
to jump mindlessly from procedure to procedure, with no specific rule as
to where code execution resumed.  Spaghetti code, anyone?

Now here's the part of the message where I'll probably stir up a
pointless debate.  I have used GOSUB statements for years in my
AccessBasic, VB and VBA code, and only recently stopped doing so because
the outdated syntax is confusing to someone unfamiliar with its use.

I personally try to avoid global variables (another debate in itself),
and limit the use of modular variables.  In routines using several
procedure-level variables, breaking an unwieldy procedure into smaller
ones involves passing multiple arguments to the child routines.  A
possible alternative is to break code blocks into separate sections of
the same routine and call it with GoSub.  Not only do you have the
benefit of sharing all of your procedure level variables, but the code
is kept bundled with your main sub.

I found this approach to be elegant and useful.  Many people would pan
it as clunky, outdated, and even arcane.  Eventually I stopped doing it
mainly for the benefit of others who have to maintain my code.





--------------------------------------------------------------------------------------------------------------------
The information in this email may contain confidential information that 
is legally privileged. The information is only for the use of the intended 
recipient(s) named above. If you are not the intended recipient(s), you 
are hereby notified that any disclosure, copying, distribution, or the taking 
of any action in regard to the content of this email is strictly prohibited.  If 
transmission is incorrect, unclear, or incomplete, please notify the sender 
immediately. The authorized recipient(s) of this information is/are prohibited 
from disclosing this information to any other party and is/are required to 
destroy the information after its stated need has been fulfilled.

Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Tappe Construction Co.

This footer also confirms that this email message has been scanned
for the presence of computer viruses.Scanning of this message and
addition of this footer is performed by SurfControl E-mail Filter software
in conjunction with virus detection software.