Fortran Style

From!!!!!!!!!gatech2!swrinde!!utnut!nott!!usenet Tue Dec 12 12:52:20 1995
Newsgroups: comp.lang.fortran
From: (Glen Reesor)
Subject: Fortran Coding Style for the Modern Programmer
Message-ID: <>
Sender: (USENET News System)
Organization: AECL-Research
X-Newsreader: knews 0.9.3
Date: Fri, 1 Dec 1995 18:40:06 GMT
Lines: 113

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

   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 

2. When making code changes, don't delete lines--just comment them out.
   (You might need them later.)


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
       result = result + a
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
<>            not my employer's.


Fortran Style — 1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Prove you\'re a person, not a bot: * Time limit is exhausted. Please reload CAPTCHA.