Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!munnari.oz.au!metro!usage.csd.unsw.oz.au!ccadfa!ghm
From: ghm@ccadfa.adfa.oz.au (Geoff Miller)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 77 Style Guide (long, REPOST)
Message-ID: <1794@ccadfa.adfa.oz.au>
Date: 5 Aug 90 23:41:31 GMT
References: <26B89BE1.4349@ics.uci.edu> <59012@lanl.gov>
Organization: Computer Centre, University College, UNSW, ADFA, Canberra, Australia
Lines: 41

jlg@lanl.gov (Jim Giles) writes:

>This is not a disagreement with the style guide David Levine gave
>but merely a commentary on it.  I say this because I will only
>discuss those parts of his submission that I disagree with. As
>a result, I might be mistaken for a dissenter.  In fact, as will
>be seen, I don't discuss most of what he says (and I therefore
>agree with those parts).

>>     3) Assign a separate sequence of labels to FORMAT labels that are grouped
>>        at the end of a subprogram.

>Same comment about "assign" plus the following: whenever possible, put
>the format into the I/O statement which uses it.  Use labeled formats
>only when several I/O statements share the same (long) format.

I may not have been the only person to contribute this recommendation to David,
but I did contribute it so I'll defend it.  If you can guarantee that every
FORMAT statement will appear immediately under (or in) the PRINT statement
that uses it, fine.  As soon as you start using the same FORMAT statement in
different places, you either have to hunt through the code or locate the
FORMAT statement separately, probably at the end.  I feel that it is more 
consistent to have a simple rule which puts them all in one place.

>> XI. Typing
>>        [...]
>>     4) Declare all variables.  Use a compiler option to ensure declaration.
>>        If no such compiler option is available, setting the implicit type of
>>        all variables to a type that is not used in the program often snags
>>        undeclared variables.  An example is:  IMPLICIT COMPLEX*16 A-Z.

>A better 'snag' is IMPLICIT LOGICAL A-Z.  Complex has the disadvantage
>that arithmetic (the most common variable use) is still legal on it.
>Logical is better because it is legal in fewer contexts.

IMPLICIT NULL is even better if your compiler allows it.  If you use 
IMPLICIT LOGICAL A-Z you may decide not to use logical variables at all,
which frankly I never found much loss.

Geoff Miller  (ghm@cc.adfa.oz.au)
Computer Centre, Australian Defence Force Academy