Charlotte Foust
cfoust at infostatsystems.com
Mon Aug 16 13:17:18 CDT 2004
I think it fell into disfavor because the principle of structured programming is one operation per routine and GOSUBs can be replaced with calls to separate routines as long as you pass the arguments required ByRef or pass them back as a result. As it functions in VBA, it means tightly coupled code, which has also fallen into disfavor. I can remember using it back in Access 2.0 but I don't recall ever using it since. Charlotte Foust -----Original Message----- From: Brett Barabash [mailto:BBarabash at tappeconstruction.com] Sent: Monday, August 16, 2004 8:38 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Naming Conventions - GOSUB = CALL? No. GOSUB redirects program execution to a label in the same procedure. CALL redirects it to another procedure entirely. In older versions of BASIC (e.g. the one that shipped with my good ol' 64), GOSUB jumped to another line in the program with the expectation that it would eventually encounter a RETURN statement to bring it back to the original routine. GOSUB is acceptable from a structured programming standpoint, but not widely used in VB(A) (don't know why, but it's obviously not a popular keyword and has been removed from VB.NET). Nothing wrong with the CALL keyword (although it has also been discontinued in VB.NET since all procedures are called with parentheses). -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin - Beach Access Software Sent: Monday, August 16, 2004 10:43 AM To: Access Developers discussion and problem solving Subject: Re: [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