Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!relay.nswc.navy.mil!oasys!roth
From: roth@oasys.dt.navy.mil (Pete Roth)
Newsgroups: comp.lang.fortran
Subject: Re: Where can I find a Fortran style guide?
Message-ID: <7920@oasys.dt.navy.mil>
Date: 23 May 91 11:30:43 GMT
References: <2167@tharr.UUCP>
Reply-To: roth@oasys.dt.navy.mil (Pete Roth)
Organization: David Taylor Research Center, Bethesda, MD
Lines: 39

In article <2167@tharr.UUCP> gombo@tharr.UUCP (Alun Jones) writes:
>Hi.
>I've reached the stage in my conversion of a large suite of Fortran that I
>feel it would be useful to inform my bosses of where I feel their program is
>'badly' written.  Although I don't have any syntax problems with their code,
>there are one or two things that I feel are bad style - using too many
>implicit variables, assuming variables are initialised to zero, mixing and
>matching variable types in common blocks, that kind of thing.
>[...]

How about 3 for the price of 1:

1. Kernighan, Brian W & P.J. Plauger, THE ELEMENTS OF PROGRAMMING STYLE,
2nd Edition, McGraw-Hill, 1978 (!)
	- a little dated now, but _still_ applicable. Even 1st edition
	is worth reading (1974! egads this stuff is old).

2. Kernighan, Brian W & P.J. Plauger, SOFTWARE TOOLS,
Addison-Wesley, 1976.
	- the documentation for Ratfor, a whole bunch of algorithms for
	text processing, sorting, macro processing, etc. Seminal.

3. Ledgard, Henry, & possibly others, PROGRAMMING PROVERBS,
can't find my copy...

These books are really exercises in common sense. They give examples of
good and bad code, and the reader can _see_ that one is "better" than
the other, but there's some difficulty convincing others without a
numerical quality measure. You might want to check into some
of the literature on software complexity. Names to look for:
McCabe, T Capers Jones.

regards,

pete

- - - - - - - - - - - - - - - - - - - - - - - - - -
Peter N Roth      roth@oasys.dt.navy.mil
Objects in this office are closer than they appear.