Fortran Coding Style for the Modern Programmer
Glen Reesor
codes, I have come across a number of, shall we say, interesting tendencies.
I attribute these tendencies to a number of things:
1. Historical limitations of compilers and hardware (very understandable--
at least for dusty-deck code, but depressing for newly written code).
2. The author being someone with zero training in how to write
maintainable, readable, quality software. (In my opinion, a very
significant factor in new Fortran software being written.)
Although, I keep telling myself that item 2 is very common, I've
lost count of the number of times I've been trying to decipher
a code segment and decided there should be an item 3:
3. The author of the code is from a different planet where their logic
is a complete reversal (yet twisted in some way) to ours :-)
So, in order to soothe my nerves, I've created a guide for writing
modern Fortran. There are two especially funny things about this list
(in my opinion, of course):
- I have encountered every single one of these (within the last 2 years)
- Most of these practices are being continued at this very moment by
some unnamed people I have encountered
So, without further delay, I give you....
Fortran Coding Style for the Modern Programmer
----------------------------------------------
1. When picking variable names, pick something meaningful then remove all
the vowels. If the result is longer than 6 characters, truncate as
required.
2. When making code changes, don't delete lines--just comment them out.
(You might need them later.)
3. WRITE ALL CODE IN UPPERCASE IT LOOKS BETTER THAT WAY.
4. There is no need to use comments because, "Fortran is self-documenting".
(Don't forget rule 1.)
5. Another good reason to leave out comments is that they cause slower
execution of your program.
6. If you must include comments, they are easiest to read if you alternate
comment lines and code lines (with the same level of indentation), with
no blank lines or 'dash' lines in between.
7. When deciding what the condition should be in an "IF-THEN-ELSE" statement,
decide what is most logical for a human to understand, then reverse it.
8. When deciding whether to put variables in common blocks or not, choose
one of the following:
a) Pass all variables on argument lists to subroutines, and put none
in common blocks. That way you know exactly where every variable
came from. It has the added benefit of reminding you to add
variables required in one routine to all routines called before it.
b) Put all variables in common blocks, and put none in the subroutine
argument list.
c) There is no (c)--you must use either (a) or (b).
9. Write your code using implicit typing--that way you don't have to type
as much.
10. To make yourself feel at home, always refer to 'cards', 'fields', 'decks'
and 'core memory'.
11. When using variables, pick one name when you calculate it, assign
it to another one for use in an argument list to another subroutine,
and call it something else inside the called routine.
(This also has the added benefit of increasing your job security.)
12. When designing the format of your ASCII inputfile, base it on a rigid
column structure so you don't have to parse any keywords in
the inputfile.
13. To make your program footprint smaller, use the same arrays for different
things, depending on which part of the program you're in.
14. When you realize that the same code segment is being written many
times, it is best to cut-and-paste multiple times rather than risk a
mistake creating a subroutine.
15. To make code more readable, write it like this:
if (a .eq. 1) then
result = result + 1
else if (a .eq. 2) then
result = result + 2
else if (a .eq. 3) then
result = result + 3
else
result = result + a
endif
16. A blank lines must start with a 'C'.
17. The Golden Rule:
Regardless of the capacity of the machine your code is to run on,
it is more important to make it small and run blindingly fast,
than to maximize program readability and maintainability.
--
Glen Reesor Opinions are mine, only mine, and definitely
<ree...@crl.aecl.ca> not my employer's.
Prof. Loren Meissner
>
> 3. The author of the code is from a different planet where their logic
> is a complete reversal (yet twisted in some way) to ours :-)
It's well known that Fortran is not used on THIS planet any more. So
that's where they are all coming from.
> Fortran Coding Style for the Modern Programmer
> ----------------------------------------------
>
You forgot to put in the REALLY BIG GRIN -- I was already on my
second reading before I noticed your tongue in your cheek.
--Loren Meissner
Kenneth Plotkin
>
> 2. The author being someone with zero training in how to write
> maintainable, readable, quality software. (In my opinion, a very
> significant factor in new Fortran software being written.)
>
A big reason for FORTRAN (and other higher level languages) was so that
people could use computers without having to program, "program" meaning to
write assembly or machine code. The target user group is scientists and
engineers, who do not get lots of software training. (Nor do we get much,
if any, machine shop training, despite many of us going on to design
physical objects.) FORTRAN programs are very often written by people who
are not thinking about the program, but about the calculation they are
doing.
Good list, though, and I'll try to follow it more carefully in the future.
Ken Plotkin
E.C. Eccleston
a "Modern Programmer?" What is so wrong about organizing coherent programs
according to the way I feel is logical? After all, I'm the one who has to
do the debugging; so why not make it easier on myself? But, then again, I'm
a dolt of an engineer--how dare I attempt to write a computer program with
the code in all caps, blank lines, and comments without a "c" surrounded
by a box:
*--------------------------------------*
* Calculate the activity coefficient *
*--------------------------------------*
GAMMA = ACTIV/MFRAC
Oh, and I use FORTRAN, not Fortran.
Eric Eccleston
eecc...@flint.mines.edu
Graduate Student
Metallurgical Engineering
Colorado School of Mines
Kenneth Plotkin
Prof. Loren Meissner <meis...@usfca.edu> wrote:
[snip]
>It's well known that Fortran is not used on THIS planet any more. So
[snip] ^^^^
Aha! So you're not from Earth, after all. ;-)
I'll keep an eye out for you as I guide Boston Low on his exploration of
Cocytus.
Ken Plotkin
Thomas Koenig
> Fortran Coding Style for the Modern Programmer
>7. When deciding what the condition should be in an "IF-THEN-ELSE" statement,
> decide what is most logical for a human to understand, then reverse it.
This was the guiding principle for JCL's COND parameter, I think.
I wonder how many people fell for your article? :-)
--
Thomas König, Thomas...@ciw.uni-karlsruhe.de, ig...@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
Prof. Loren Meissner
>
> What if, like myself, you're not (nor do you have any intention of becoming)
> a "Modern Programmer?" What is so wrong about organizing coherent programs
> according to the way I feel is logical? After all, I'm the one who has to
> do the debugging; so why not make it easier on myself?
Programs have to be read as well as written. You might even have to
read it yourself after you have forgotten what you had in mind when
you wrote it.
Somebody told me last month that he is using a program I wrote more
than 20 years ago -- never heard of me until he saw the same name
on the program he was using and on c.l.f. Programs have a way of lasting
longer than you expect, and they will have to be read and maintained by
people who never heard of you.
It's a lot like literary style. You don't have to conform to some
"old maid English teacher" set of rules, but you have to do something
sensible. You can use upper case or lower case in various combinations,
put spaces after parens and around + signs or leave them out.
But if you do something consistent you will be able to figure it out
yourself, and the guy who comes after you and has to maintain your code
after you have gone elsewhere will be able to figure it out too.
It's nice if you can develop a sense of programming style for yourself,
so you can say, "This program is actually readable -- I can look at
the statements and figure out what is going on." You don't have to use
someone else's set of rules to do this, if you can make it really
look good to yourself. [see also Hamlet, I, ii, 78]
--Loren Meissner
Rick Lutowski
>In my (relatively) short time modifying and working with legacy Fortran
>codes, I have come across a number of, shall we say, interesting tendencies.
>I attribute these tendencies to a number of things:
>
> 1. Historical limitations of compilers and hardware (very understandable--
> at least for dusty-deck code, but depressing for newly written code).
You forget that all government agencies must use 20 year old hardware
because of the procurement cycle.
> 2. The author being someone with zero training in how to write
> maintainable, readable, quality software. (In my opinion, a very
> significant factor in new Fortran software being written.)
Please supply the name and number of the software maintainability
course at _your_ institution of higher learning.
> 3. The author of the code is from a different planet where their logic
> is a complete reversal (yet twisted in some way) to ours :-)
Of course. Men are from Mars and women are from Venus. (Men have
to maintain women's code and vise-versa.)
>So, in order to soothe my nerves, I've created a guide for writing
>modern Fortran. There are two especially funny things about this list
>(in my opinion, of course):
>
> - I have encountered every single one of these (within the last 2 years)
> - Most of these practices are being continued at this very moment by
> some unnamed people I have encountered
>
>So, without further delay, I give you....
>
>
>
> Fortran Coding Style for the Modern Programmer
> ----------------------------------------------
>
>1. When picking variable names, pick something meaningful then remove all
:
>17. The Golden Rule:
I'll have you know that MY code meets ALL 17 of these criteria.
(Damn, an I a good programmer, or what!)
Rick Lutowski
--
+-----------------------------------------------------------------+
| Rick Lutowski o...@iah.com 713-332-7281 |
| Object Access http://www.iah.com/oa/ 713-554-7617 |
| --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- |
| The source for Programmer's Reusable Libraries (TM) oa=OO |
+-----------------------------------------------------------------+
Rick Lutowski
>
>Good list, though, and I'll try to follow it more carefully in the future.
>
>Ken Plotkin
Please send money for the flowers for Ken's funeral to Object
Access at...
Prof. Loren Meissner
.. You don't have to use
> someone else's set of rules to do this, if you can make it really
> look good to yourself. [see also Hamlet, I, ii, 78]
You guessed it.
"This above all, -- to thine own self be true;
And it must follow, as the night the day,
Thou canst not then be false to any man."
--Loren Meissner
Glen Reesor
hindsight, some of the comments seem a bit harsh. (If I've offended
anyone, apologies are offered.)
"Prof. Loren Meissner" <meis...@usfca.edu> writes:
> You forgot to put in the REALLY BIG GRIN -- I was already on my
> second reading before I noticed your tongue in your cheek.
You're right! I just figured it was obvious :-) When I showed it to
a friend of mine, we were rolling around on the floor laughing (figuratively
speaking) by the end of it!
kplo...@access2.digex.net (Kenneth Plotkin) writes:
> FORTRAN programs are very often written by people who
> are not thinking about the program, but about the calculation they are
> doing.
This is very true. Hopefully I haven't offended anyone with my "zero
training" comment. It wasn't meant that way. It was a great tension
release, though!
One thing I'd like to point out regarding this issue of training. I think
it's common-knowledge what happens to programs (written in any language,
by any type of person) that develop and grow without serious thought
about "software" issues. The program starts off small and effective.
As time goes on, it keeps growing. Unfortunately, unless some
time is spent considering the software issues (as opposed to numerical,
or mathematical), you can quickly end up with a program:
- very difficult to understand
- very difficult to modify without inadvertently affecting other parts
of the program
- that is not understood by any one person
When a program reaches this stage, the following phrase may be heard
alot when modifications are required:
"Don't touch this part of the program--it works, but we're not exactly
sure why"
And it doesn't take much to end up like that--20000 lines of code can quite
easily become unmanageable. Yet, this is relatively small as far as modern
software projects go.
Well, enough of my ranting and raving. If anyone has anything to add to
the list, feel free to pass it on.
The Graphical Gnome
EECC...@FLINT.MINES.EDU (E.C. Eccleston) wrote:
>What if, like myself, you're not (nor do you have any intention of becoming)
>a "Modern Programmer?" What is so wrong about organizing coherent programs
>according to the way I feel is logical?
>After all, I'm the one who has to
>do the debugging; so why not make it easier on myself?
Are you ?
I'm now in the process of recoding a program original written with that kind
of thought in mind back in 1968.
It was not written by me, maintained for 25 years (not be me), and now have
to work with it.
It is FORTRAN II-ish with FORTRAN IV-ish extentions and some joker also did
some maintenance in Fortran 77.
It was written and maintained by chemical engineers, and now a software
engineer has to rebuild it using the modern techniques and Fortran-90.
This code is unmaintable, unreadble. It can only be used as an example of the
way it should not be done.
Never think you are the only one using the software you're building. If you
have to build for a living, you will stick with tha bad habit.
R.E. den Braasem (ka The Graphical Gnome (r...@ktibv.nl))
Glen Reesor
tho...@galileo.ifa.hawaii.edu writes:
> For someone being facetious, I'm puzzled by the inclusion of:
>
> > Fortran Coding Style for the Modern Programmer
> > ----------------------------------------------
> >
> > 3. WRITE ALL CODE IN UPPERCASE IT LOOKS BETTER THAT WAY.
>
> At least under FORTRAN 77 and earlier, uppercase was required for a
> standard-conforming program. It has nothing to do with looking better.
> I certainly wouldn't blame the previous programmer if I had to maintain
> FORTRAN 77 code that was written in uppercase.
Agreed. However it'd be nice to deal with newly written code that doesn't
yell at you :-) I think you'd be hard pressed to find an F77 compiler
today that did not accept lowercase (interestingly, even the F90 standard
doesn't *require* the acceptance of lowercase).
One point you missed as being nonstandard F77 was item 9. which suggests
using 'implicit none'--another nonstandard feature that is available
on every F77 I've seen (of course I don't pretend to have seen all
current F77 compilers).
> The following fall into the sometimes yes, sometimes no category:
>
> > 1. When picking variable names, pick something meaningful then remove all
> > the vowels. If the result is longer than 6 characters, truncate as
> > required.
>
> Are you advocating picking something unmeaningful?
As you pointed out above, I am being facetious.
> Or are you suggesting
> that there is something wrong with using HMWRK as a variable name for a
> homework score, for example, especially when it needs to be distinguished
> from an exam score?
HMWRK is perfectly understandable in this context. However, consider
one subroutine with a few hundred lines of code, 30 variables each of
a maximum length of 6 characters (and thus quite cryptic), and of
course with very few or no comments describing what each variable is used
for or what the subroutine is attempting to accomplish. Finally, this
subroutine was written by someone else and you must figure out what it
does so you can modify it. Not a pretty sight!
By the way, this is another item that is required for strict F77
compliance. And once again I think you'd find it challenging finding
a current compiler that enforces the 6 character variable name limit.
31 characters seems to be a common maximum length.
> > 2. When making code changes, don't delete lines--just comment them out.
> > (You might need them later.)
>
> For testing purposes, it's faster than copying the code to a file, if the
> number of lines to be commented out is sufficiently small.
Agreed. In fact, this is often how I work. But once a version of the
code is installed or frozen (pick your terminology), commented-out lines
shouldn't be there. This becomes more of an issue if you
have a build-up of commented-out code dating back a number of years.
The only purpose I can see for commented-out code in an installed
version is so one can easily revive earlier functionality--if you're
doing this you obviously don't have a good version control system
(if any).
By the way, you may be wondering what nonstandard F77 I use (since I am
being so picky and harsh :-). Basically I limit it to:
- lowercase letters
- '_' in variable and subroutine names
- long variable names (I doubt I've ever gotten past 15 characters)
- implicit none
And yes I'd like to move to F90. However, it's not in the cards yet.
My 2 cents.
tho...@galileo.ifa.hawaii.edu
For someone being facetious, I'm puzzled by the inclusion of:
> Fortran Coding Style for the Modern Programmer
> ----------------------------------------------
>
> 3. WRITE ALL CODE IN UPPERCASE IT LOOKS BETTER THAT WAY.
At least under FORTRAN 77 and earlier, uppercase was required for a
standard-conforming program. It has nothing to do with looking better.
I certainly wouldn't blame the previous programmer if I had to maintain
FORTRAN 77 code that was written in uppercase.
The following fall into the sometimes yes, sometimes no category:
> 1. When picking variable names, pick something meaningful then remove all
> the vowels. If the result is longer than 6 characters, truncate as
> required.
Are you advocating picking something unmeaningful? Or are you suggesting
that there is something wrong with using HMWRK as a variable name for a
homework score, for example, especially when it needs to be distinguished
from an exam score? (Please don't respond by saying "use a spreadsheet".)
On the other hand, there is no need to name an exam score variable XM.
> 2. When making code changes, don't delete lines--just comment them out.
> (You might need them later.)
For testing purposes, it's faster than copying the code to a file, if the
number of lines to be commented out is sufficiently small. For production
code, there is probably little reason to leave it in.
Mike Sestak
: In article <49qbk5$g...@magma.Mines.EDU>,
: Are you ?
It is strange the way the world works. Most Fortran code probably was
originally written by scientists and engineers for one time use to solve a
particular problem. In some cases others saw, hey that version works
really well, I'll use it (but, I must modify it for my own purposes, not
to mention change things around to suit my on tastes/whims/need to mark my
territory). Then the organized MIS types take some subset of these
slightly successful programs and make them "standards" that everyone in
the company or agency must use for that purpose. They get organized into
libraries with all the accutriments of "modern computer science." If only
those slugs that invented FORTRAN II had developed Object Oriented
Programming (or the next big thing) at the same time, this code reuse
would have gone much more smoothly -- right :<)
Michael Sestak
National Biological Service
mik...@storm.cnr.colostate.edu
Reality is just a simulation model that works!
It was probably written in FORTRAN
tho...@galileo.ifa.hawaii.edu
>> For someone being facetious, I'm puzzled by the inclusion of:
>>> 1. When picking variable names, pick something meaningful then remove all
>>> the vowels. If the result is longer than 6 characters, truncate as
>>> required.
>> Are you advocating picking something unmeaningful?
> As you pointed out above, I am being facetious.
Precisely. You suggested that something meaningful be picked, and you
were being facetious, which is why I asked if you were advocating
picking something unmeaningful.
I.J....@dl.ac.uk
I missed the original post, or it didn't appear here
for some reason. From what I have seen it looks a
very important document :) and I would dearly like
a copy. Could someone either email me the original
or repost it ?
Ian
David Chamont
I use to code with C++, but have some interest in Fortran.
Most of the following rules of coding sounds to me like a
real joke !
I would like very much to know if the Fortran Community agree
with this coding style, especially the "Golden Rule".
David.
The Graphical Gnome
cha...@loria.fr (David Chamont) wrote:
>
>I use to code with C++, but have some interest in Fortran.
>Most of the following rules of coding sounds to me like a
>real joke !
C DAVID
SUBROUTINE EMPTY
C IT IS ONE BIG JOKE
RETURN
C THE
END
;)
Markus Turunen
...snip
>I'm now in the process of recoding a program original written with that kind
>of thought in mind back in 1968.
>
>It is FORTRAN II-ish with FORTRAN IV-ish extentions and some joker also did
>some maintenance in Fortran 77.
We easily forget the primitive environment, where scientists and engineers
often wrote those old programs. There was not any screen where you could
immediately see what you are writing, and editors were often very
userunfriendly. So you were discouraged to write verbose comments.
And I remember that 1960's there was a school of thought that source code
should not be readable by itself, it only has to do job well.
I also remember making corrections into a deck of cards containing a fortran
program by hand, sometime 1960's.
regards,
--
** Markus Turunen ** scientist ** Vaisala Oy ** Finland **
rfri...@vcnet.com
> In article <DJ45y...@ktibv.nl>, r...@ktibv.nl says...
> ...snip
>
>
> often wrote those old programs. There was not any screen where you could
> immediately see what you are writing, and editors were often very
> userunfriendly. So you were discouraged to write verbose comments.
>
> And I remember that 1960's there was a school of thought that source code
> should not be readable by itself, it only has to do job well.
>
> ** Markus Turunen ** scientist ** Vaisala Oy ** Finland **
>
>
>>>>
Any other of you old timers out there remember how to 'cheat' on 026 key punch?
You could duplicate a card, and by jamming your thumb firmly on the input card,
punch a couple of characters onto the output card. VOila! Character insert into
a source statement.....
_______________________
|Ralph Jay Frisbie |
|A flying saucer lover, |
|but not the inventor. |
|rfri...@vcnet.com |
|-----------------------
Clive Page
a couple of points, so can I suggest a couple more?
18. FORMAT statements are messy and hard to get right, so it makes sense
to tuck them out of the way, well away from the READ and WRITE
statements that they have to work with. If you can, stick them all
just before the END statement; that way if you change the code and
remove some of the READs/WRITEs so some of the FORMATs are no longer
used, no-one will notice and it won't matter.
19. The END DO statement isn't in the Fortran 77 Standard, and the CONTINUE
is just a waste of space, so make sure you end all your DO loops on
labelled executable statements. The more loops you can terminate on one
statement the more efficient it is likely to be.
20. Statement labels can be anything from 1 to 99999, so the best way to
pick a unique one is to use a table of random numbers. The chances of
choosing two labels the same in the same program unit are pretty tiny.
--
-------------------------------------------------------------------------
Clive Page, Internet: c...@star.le.ac.uk
Dept of Physics & Astronomy,
University of Leicester.
Iain A F Fleming
In article <4a6adq$1...@ankka.csc.fi>,
mtur...@finsun.csc.fi (Markus Turunen) wrote:
>
> I also remember making corrections into a deck of cards containing a
> fortran program by hand, sometime 1960's.
I remember doing this in the early 1980's! (but I was a geographer back then).
--
Iain A F Fleming Compiler Group Micro Development Tools
SGS-THOMSON Microelectronics Bristol UK +44.1454.611537
Marty Cohen
the argument list, is simply to put VARIABLES in common, and
VALUES in argument lists. I try never to pass variables between
program units. (Of course, there are often compromises due to
the need for speed or cutting down the profusion of names in a
routine - probably all due to poor basic design:-)
In general, object-oriented design seems to imply that any
variable will be an attribute of an object, and therefore
hidden in a module. Communication between modules will be
accomplished entirely by the passing of values (messages).
There should be no concept of a variable across modules.
--
Martin Cohen, AMSAA-LAD mco...@arl.mil Custom House Rm 800, Phila. PA
19106-2976 (215)597-8377 Fax (215)597-2240 (Not the Northrop Cohen)
Marty Cohen's Home Page href=http://www.netaxs.com/~mcohen/
Ben Weiner
fluid dynamics code) I just have one thing to add, even though
the thread is old.
gl...@cu71.crl.aecl.ca (Glen Reesor) writes:
>In my (relatively) short time modifying and working with legacy Fortran
>codes, I have come across a number of, shall we say, interesting tendencies.
>I attribute these tendencies to a number of things:
...
>8. When deciding whether to put variables in common blocks or not, choose
> one of the following:
> a) Pass all variables on argument lists to subroutines, and put none
> in common blocks. That way you know exactly where every variable
> came from. It has the added benefit of reminding you to add
> variables required in one routine to all routines called before it.
> b) Put all variables in common blocks, and put none in the subroutine
> argument list.
> c) There is no (c)--you must use either (a) or (b).
My addition: Please remember that common blocks have a critical
advantage for certain applications. If you want to make your code
more compact, or avoid indirection, or you don't trust the optimizing
compiler that you didn't have when you first wrote the code, you can
always WIN BIG by accessing arrays out of bounds inside the common
block. It's just like hacking assembler!!
I'd laugh, if I wasn't crying.
--
dept of physics & astronomy, rutgers university pipe stress freak
exit 9, new jersey turnpike, new jersey crystallography weenie
Toon Moene
[ ... Tongue in cheek, no doubt ... ]
> 19. The END DO statement isn't in the Fortran 77 Standard, and the
> CONTINUE is just a waste of space, so make sure you end all your DO
> loops on labelled executable statements. The more loops you can
> terminate on one statement the more efficient it is likely to be.
Unfortunately, however logical this may sound, for at least one FORTRAN 77
conformant processor the opposite is true.
Try the difference between:
DOUBLE PRECISION FUNCTION DOT(X,Y,N)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
DIMENSION X(N), Y(N)
DOT = 0.0D0
DO 10 I=1,N
10 DOT = DOT + X(I)*Y(I)
RETURN
END
and:
DOUBLE PRECISION FUNCTION DOT(X,Y,N)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
DIMENSION X(N), Y(N)
DOT = 0.0D0
DO I=1,N
DOT = DOT + X(I)*Y(I)
ENDDO
RETURN
END
when unrolling loops for g77 (i.e. g77 -O2 -funroll-loops ...)
--
Toon Moene (to...@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
URL: http://www.knmi.nl/hirlam