Re: Use of subroutines

From: Ken Plotkin (kplotkin_at_nospam-cox.net)
Date: 02/28/04 

Date: Sat, 28 Feb 2004 13:29:24 -0500

On 28 Feb 2004 04:16:20 -0800, pterostyrax@yahoo.com (Pterostyrax)
wrote:

[snip]
>GOTOs, I have not misunderstood the problem. Indeed, there is one
>instance of a GOTO in my program that actually aids in following the
>logic in the program, where trying to have 100% modular code would
>have obfuscated an important part of the logic. I used the word

Go tos are not evil. Trying to write a program with no go tos can be
evil - there are times where you just need to jump someplace.

>"indiscriminate" very carefully as this is the essence of the problem,
>as you rightly point out. I was simply trying to point out that the
>"indiscriminate" use of subroutines is essentially the same as the
>"indiscriminate" use of GOTOs that results in code that becomes almost
>incomprehensible and therefore unmaintainable.

Indiscriminate use of anything can be evil. You generally have to
work at it to make too many subroutines into a problem. It's really
easy to make a mess with too many go tos.

[snip]
>I still maintain that a subroutine is first and foremost a GOTO
>statement. In essence, and more importantly in practice, a call to a
>subroutine says "okay, stop right in the middle of what you are doing,
>go to a physically removed place in the code, try to understand logic
>in a new environment with new variable names that may or may not
>correspond to variable names you are previously familiar with
[snip]

Actually, quite the opposite. Calling a subroutine means to do some
predefined operation on stuff you have, and come back with the
results. You don't need to know how it was done. Often you don't
care. All you know is that you asked for something and got it.

Kind of like sending out for a pizza.

IMHO, the proper mindset for writing a subroutine is to think of
isolating tasks, so that once a managable task is subroutinized you're
done, and never have to mess with it again. Nor worry about its
interaction with the program, other than via specifically defined
variables.

Ken Plotkin

Relevant Pages

  • Re: a goto command???
    ... >> I hope it's clear that I agree with you that goto is not always evil. ... > Sorry about that snip. ... Well, *we* can't do anything about it, only TMW can. ...
    (comp.soft-sys.matlab)
  • Re: slightly OT: error handling conventions
    ... >- goto is evil and should be avoided whenever possible ... There must have been important changes to the universal timeline ...
    (comp.lang.c)
  • Re: Problem writing code to go to a label after calling a procedure
    ... >>I first tried to create procedures for parts of the program to avoid ... Thanks for the advice J French. ... I know a good program structure avoids many goto ... subroutine, this is somthing I found that Visual Basic can't do. ...
    (comp.lang.basic.visual.misc)
  • Re: Exit Sub not exiting
    ... After trying this, then deleting the subroutine, ... Judy Hopkins ... This happened once before in another workbook, ...
    (microsoft.public.excel.programming)
  • Re: Use of subroutines
    ... >>I still maintain that a subroutine is first and foremost a GOTO ... > GOTO transfers control with no provision to return and continue ... > continue execution. ...
    (comp.lang.fortran)