Re: Subroutines vs Subprocedures was RE: Indicators

I tried to stay out of this one, but this caught my eye and tugged at
my heartstrings:

> Are you saying that you use "begsr" as
> documentation that tells the next
> programmer "this uses globals" and the
> P-spec as documentation that says
> "this doesn't use globals?"

I realised that subconsciously, this is me!  Like Joe Pluta, I have a
long history of writing subroutines to process display panels, and
that habit hasn't gone away even though I am a strong supporter of
subprocedures and service programs.  This thread has lead me to start
thinking about _why_ I write code this way as opposed to switching
completely over to subprocedures.

A typical interactive program will go something like this:

loop
  exfmt main_panel
  exit?
  exsr process_main
end loop

begsr process_main
  eval valid = checkThisOrThat(SCREENFLD)
  callp blahBlah(SCREENFLD2)
  if valid
    loop
      exfmt child_panel
      exit?
      exsr process_child
    end loop
endsr

And so on.  It turns out that the subprocedures Very Rarely use global
variables; they take display fields as their input/outputs.  The
subroutines are swarming with global references to display and
database files.  Virtually none of the I/O happens in a procedure; all
of it happens in a subroutine.  So for me, the answer is Yes - BEGSR
is the clue that I'm doing I/O (global variables) or consolidating
several related functions into a stream of temporally related lines of
code.

That is, if I have a block of code that logically means 'validate the
display entry fields' my first thought is to put that into a
subroutine.  When I want to validate a specific display field as a
date, my first thought is to put that into a procedure.  I guess that
I'm slavishly following the dictum that a procedure does one thing,
and one thing well.

One thing is certain; this thread has made me think and re-think about
why I write the way I do.
  --buck