nraoaoc@nmt.edu (Daniel Briggs) (08/04/90)
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)shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (08/06/90)
In article <1990Aug4.011300.17395@nmt.edu> dbriggs@nrao.edu (Daniel Briggs) writes: >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 I interpreted the style guide to prohibit not the appearance of more than one RETURN in a subroutine, but rather to prohibit "RETURN n", transferring control to different places in the calling routine, depending on the value on n. From my point of view, the problem with ENTRY is how complicated it is for a human to analyse what is going on in someone else's code. I accept that there may be smple cases where analysis is easy, but I've learned to shudder whenever I encounter an ENTRY in someone else's code, and I tend to avoid it in my own, largely because I hate to make other people shudder. (Confession: I once used some ENTRY points, and coming back to the code later, I myself shuddered.... That's what really did it for me!) -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixc.cc.columbia.edu(Internet) shenkin@cunixc(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***
ghm@ccadfa.adfa.oz.au (Geoff Miller) (08/15/90)
nraoaoc@nmt.edu (Daniel Briggs) writes: >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? Maintainability. When you have had to maintain large chunks of unstructured FORTRAN in which each (long) subroutine has multiple entry and exit points, you become slightly paranoid on the subject. Also, as I pointed out in another connection, it is better to have one simple rule to follow than to have rules which depend on the surroundings. > ...examples and discussion deleted... >.... 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? Any Style Guide is an ideal. How rigidly you apply it (or have your staff apply it) is up to you, and I would be the first to admit that in some cases the very nature of FORTRAN can make stylistically pure code appear ugly. It comes back always to maintainability, and there will always be some room for judgement. Actually, the only point where I bend the one-entry-one-exit rule is in the case of an emergency stop - for example, where a program is designed to maintain two consistent data files, and yet it detects an inconsistency. In this case I stop the program with an informative (to me :-) message, because I have obviously got something drastically wrong somewhere. Geoff Miller (ghm@cc.adfa.oz.au) Computer Centre, Australian Defence Force Academy