Re: Use of subroutines

From: Pterostyrax (pterostyrax_at_yahoo.com)
Date: 02/29/04 

Date: 28 Feb 2004 15:11:32 -0800

Ken Plotkin <kplotkin@nospam-cox.net> wrote in message news:<ufm1405asnpcbotopu412g8pe74241acji@4ax.com>...
> 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.
>

Obviously, I disagree as this was the point of my OP.

> [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

Again, the whole point of my original post has been about the flow of
logic, particularly with regards to allowing other people to easily
understand the flow thereof. The original programmer may never have
to mess with a subroutine again, but someone unfamiliar with the code
is going to have to go to the subroutine and figure out if how the
pizza was made is important to understanding the overall purpose of
the pizza - whew, talk about a strained metaphor. Again, I am simply
trying to point out that the original programmer, if he gives some
thought to the readability of the code, is the best person to decide
what is or is not important to the understanding of the code - rule a.

Relevant Pages

  • 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: 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)
  • Re: Use of subroutines
    ... Go tos are not evil. ... >I still maintain that a subroutine is first and foremost a GOTO ...
    (comp.lang.fortran)
  • Re: When MV is not an option
    ... Each prompt calls a local subroutine to validate some test. ... a GoTo or STOP. ... >programming language... ...
    (comp.databases.pick)