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.

 >    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.

Good list, though, and I'll try to follow it more carefully in the future.

*--------------------------------------*
*  Calculate the activity coefficient  *
*--------------------------------------*
        GAMMA = ACTIV/MFRAC

Oh, and I use FORTRAN, not Fortran.

[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.

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]

.. You don't have to use

"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."

"Prof. Loren Meissner" <meiss...@usfca.edu> writes:

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.

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.

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).

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.

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.

The following fall into the sometimes yes, sometimes no category:

: >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))

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 :<)

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 ?

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".

|>
|>                     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
|> <rees...@crl.aecl.ca>            not my employer's.
|>

;)

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,

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.

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).

I'd laugh, if I wasn't crying.