Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!rutgers!maverick.ksu.ksu.edu!unmvax!nmt.edu!nraoaoc
From: nraoaoc@nmt.edu (Daniel Briggs)
Newsgroups: comp.lang.fortran
Subject: More Style Points -- One Entry, One Exit?
Message-ID: <1990Aug4.011300.17395@nmt.edu>
Date: 4 Aug 90 01:13:00 GMT
Reply-To: dbriggs@nrao.edu (Daniel Briggs)
Organization: National Radio Astronomy Observatory, Socorro NM
Lines: 65

As long as we are discussing style points, here's one I have wondered
about.  Why are people SO adamant about the ONE entry, ONE exit point
of view?  I grant you that from a CS "proof of correctness" point of
view, it is certainly the most convenient form to analyze.  Likewise,
one can create some awful code with indiscriminate use of ENTRY and
RETURN statements.  Still are these issues so important from a
practical point of view that we should never use alternate constructs?
(I know that this is largely a matter of taste, but I am trying to see
what the prevailing opinion is.)  For a simple example, I don't really
see that the following code fragment is particularly unreasonable.
(Allow me a modest set of extensions, please....)

C Normal Return
 900  type *, 'All is OK'
      return
C Error Return
 990  type *, 'Error condition'
      return
      end

Is this really any worse than the form

C Normal Return
 900  type *, 'All is OK'
      go to 999
C Error Return
 990  type *, 'Error condition'
 999  return
      end

I might argue that the first form is in fact more aesthetically
pleasing and clearer.  Alternate entries are a little harder to
justify, but at least one reasonable use jumps to mind.  How about a
subroutine that needs initialization which involves a parameter.  The
invokation of the subroutine does not need this parameter, but
requires several others.  I'm thinking of something like

      subroutine CALC_MODEL (parm1,parm2,parm3)
      ...stuff...
      return
      entry INIT_MODEL (table_size)
      ...sets up local calculations...
      return
      end

The alternatives might be to pass an initialization parameter around
that is never used after the first call.  Something like

      call CALC_MODEL (dummy, dummy, dummy, table_size)

the first time, and

      call CALC_MODEL (parm1, parm2, parm3, dummy)

on all subsequent invokations.  Ugly, but it seems to be fairly common
practice.  One could have separate calculation and initialization
subroutines, but then you need COMMONs so that they can communicate.
This seems even uglier.  So, style gurus, what are your opinions?  Do
you stick religiously to one entry, one exit, or do you bend the rules
a bit when it makes for clearer code?

-- 
This is a shared guest account, please send replies to
dbriggs@nrao.edu (Internet)
Dan Briggs / NRAO / P.O. Box O / Socorro, NM / 87801  (U.S. Snail)