[AccessD] Naming Conventions - GOSUB = CALL?

Is GOSUB the same As CALL in VBA?  I CALL a lot of subroutines.

(I know I can drop the CALL but it reads more clearer when I use it.  )

Is this bad form?

Rocky

----- Original Message ----- 
From: "Jim Lawrence (AccessD)" <accessd at shaw.ca>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Saturday, August 14, 2004 10:56 AM
Subject: RE: [AccessD] Naming Conventions


> Hi Brett:
>
> I must admit I never read anything directly actual panning GOSUBS and I
can
> see you point about them being similar to function/subroutine calls. In
the
> older coding environments there were little flexibility when it came to
> selection.
>
> Dijkstra's main emphasis was on pushing for structured coding. With the
> creation of structured languages came all the amenities and designing
> choices that we, as developers enjoy today. He did not condemn use of
> particular code statements but rather, he encouraged the development of
> structured development languages.
>
> Jim
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Brett Barabash
> Sent: Saturday, August 14, 2004 9:11 AM
> 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.
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
> (AccessD)
> Sent: Saturday, August 14, 2004 3:29 AM
> To: Access Developers discussion and problem solving
> Subject: RE: [AccessD] Naming Conventions
>
> John:
>
> You might find this article, about the man who spent a major portion of
> his life condemning the GOTO and GOSUB commands, interesting. Quote: He
> was famously the leader in the abolition of the GOTO statement from
> programming.
>
> http://reference.creativesystemdesigns.com/miscellaneous.html#edsger
>
> Jim
>
>
> --------------------------------------------------------------------------
--
> ----------------------------------------
> 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.
>
> --
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> -- 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com