Home > Archive > Fortran > September 2006 > Fortran code styles
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Fortran code styles
|
|
| Stanislaus 2006-08-31, 7:00 pm |
| Hello,
Are there any code styles for Fortran? Official or not. And what do you
prefer?
| |
|
|
| Jim Klein 2006-09-01, 4:00 am |
| "Stanislaus" <FedorovStanislav@mail.ru> wrote:
>Hello,
>
>Are there any code styles for Fortran? Official or not. And what do you
>prefer?
Fortran Style. Isn't that a little like Military Intelligence ?
We got a dump truck full of "science code" for one of the proposed
NPOESS instruments at my last day job (I don't mention the name to
save the coder from embarassment).
GOTOs and STOP stamements abounded. Not a comment to be found. I
didn't think people still wrote in Fortran IV.:-)
All kidding aside, Lawson Wakefield and crew with Winteracter should
be looked at as a guide for old Fortran 77 coders. Their examples are
rather good guides.
The most important thing is not the style, it is a minimum of one
comment line for most lines of code so that when you retire, the poor
bastard who inherits your code doesn't commit suicide trying to figure
out what you wrote.
This very thing in happening two cubicals away from me and I say a
prayer of thanks that I did not get the assignment to maintain that
code.
James E. Klein
jameseklein@earthlink.net
Engineering Calculations
http://www.ecalculations.com
ecalculations@ecalculations.com
Engineering Calculations is the home of
the KDP-2 Optical Design Program
for Windows and (soon) MAC OSX
Free KDP-2 (DEMO) downloadable!
1-818-507-5706 (Voice and Fax)
| |
| Richard Maine 2006-09-01, 4:00 am |
| Jim Klein <jameseklein@earthlink.net> wrote:
> The most important thing is not the style, it is a minimum of one
> comment line for most lines of code so that when you retire, the poor
> bastard who inherits your code doesn't commit suicide trying to figure
> out what you wrote.
I have to disagree with that, because I've seen too many codes written
with exactly that rule. This results in code like
c Assign 3 to x
x = 3
or even worse
c Assign 3 to x
x = 4
Yes, I know that you meant useful comments. But since "useful" is a
subjective judgement, that part gets dropped and you end up with rules
like "have at least one comment line for every line of code."
Bureaucracies (like the one I work for) are fond of simple objective
criteria like that - the are so much easier than thinking. The fact that
this completely misses the point of the rule in the first place is, I'm
afraid, lost. Yes, it does happen that such rules get applied like that;
I've seen it.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Tobias 2006-09-01, 4:00 am |
| Hello,
Jim Klein wrote:
> The most important thing is not the style, it is a minimum of one
> comment line for most lines of code so that when you retire, the poor
> bastard who inherits your code doesn't commit suicide trying to figure
> out what you wrote.
What I like most in terms of comments is:
a) some short comment at the beginning of each file, to know from a
glance what that file is about
b) Each function which is not self-explanatory should have some short
comment what that function does; analogously for type or global
variables
c) Special or highly optimized code should have some comment; similar a
reference from which article some code has been taken from.
As Richard Maine I don't need comments like "! Assigne a to b".
The reason for the comment types I mentioned above is: Usually with a
new program I know that the thing I need is is subroutine foo, but
reading that several global variables/argument, functions are called.
And then such a comment helps.
Tobias
| |
| Brooks Moses 2006-09-01, 4:00 am |
| Richard Maine wrote:
> Jim Klein <jameseklein@earthlink.net> wrote:
>
> Yes, I know that you meant useful comments. But since "useful" is a
> subjective judgement, that part gets dropped and you end up with rules
> like "have at least one comment line for every line of code."
> Bureaucracies (like the one I work for) are fond of simple objective
> criteria like that - the are so much easier than thinking. The fact that
> this completely misses the point of the rule in the first place is, I'm
> afraid, lost. Yes, it does happen that such rules get applied like that;
> I've seen it.
And, not to reopen the old argument too far, but in my opinion it's at
least as important to write code that's comprehensible. I won't go so
far as to say that good code shouldn't need comments at all, but I do
think that "per line of code" is rather the wrong dimension of unit to
measure it with -- lines of code, as such, should be clear enough to
never need comments. Equations, algorithms, complex data structures,
information flow, those on the other hand often do need comments, to
explain where they came from and sometimes why they were chosen. But
those comments are almost never at the line-of-code level.
- Brooks, who tends to put equation derivations and literature citations
in his comments every so often. When I look at my code three years from
now, I want to be able to check to make sure the math was right!
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Brooks Moses 2006-09-01, 4:00 am |
| Tobias wrote:
> What I like most in terms of comments is:
> a) some short comment at the beginning of each file, to know from a
> glance what that file is about
> b) Each function which is not self-explanatory should have some short
> comment what that function does; analogously for type or global
> variables
> c) Special or highly optimized code should have some comment; similar a
> reference from which article some code has been taken from.
Agreed. Another thing that I find useful is a description of the
assumptions embodied in the code. For instance, when a subroutine has a
certain expectation about its inputs -- "Note that it is legal to assign
a field variable to a grid before defining the points of the grid", to
pick an example from what's currently in my editor -- that's useful to
document in the comments at the head of the comment.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| David Flower 2006-09-01, 4:00 am |
|
Richard Maine wrote:
> Jim Klein <jameseklein@earthlink.net> wrote:
>
>
> I have to disagree with that, because I've seen too many codes written
> with exactly that rule. This results in code like
>
> c Assign 3 to x
> x = 3
>
> or even worse
>
> c Assign 3 to x
> x = 4
>
> Yes, I know that you meant useful comments. But since "useful" is a
> subjective judgement, that part gets dropped and you end up with rules
> like "have at least one comment line for every line of code."
> Bureaucracies (like the one I work for) are fond of simple objective
> criteria like that - the are so much easier than thinking. The fact that
> this completely misses the point of the rule in the first place is, I'm
> afraid, lost. Yes, it does happen that such rules get applied like that;
> I've seen it.
>
> --
> Richard Maine | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle | -- Mark Twain
I entirely agree, which is not to say that rules are not useful, e.g.
All DO indices, implied DO indices and dummy arguments possibly
corresponding thereto should have initial letter I. No other variables
should. The advantage of this is that the statement I = 42 is an
obvious error.
Or, in you example:
C Number of points for a dropped goal
X = 3
Dave Flower
| |
| Richard Edgar 2006-09-01, 7:00 pm |
| Jim Klein wrote:
> "Stanislaus" <FedorovStanislav@mail.ru> wrote:
>
> The most important thing is not the style, it is a minimum of one
> comment line for most lines of code so that when you retire, the poor
> bastard who inherits your code doesn't commit suicide trying to figure
> out what you wrote.
Although I'd say that comments are important, I'd disagree with that
rule - for the reasons others have outlined in their replies.
Personally, the most important thing for me is that IMPLICIT NONE
appears in every scoping unit. If I'm given a code, then the absence of
such a declaration means that I'm going to be very leary of the code.
Compilers usually do a default initialisation to zero, and so implicit
typing can turn typos into quite subtle bugs.
Some other personal style points:
- Everything goes into MODULEs, to make sure interfaces are explicit
- All modules have an unqualified PRIVATE statement
- All functions and subroutines have INTENT declared on their arguments
- I use REAL with KIND specified (according to a PARAMETER in a "Kinds"
module), not DOUBLE PRECISION
- Functions don't have side-effects, and don't modify their arguments
However, I don't count WRITE(*,*) and STOP as side effects in this. I
basically try to make functions PURE, but those exceptions prevent me
declaring them as such
- EXITs always go to a named label
- No GOTO, COMMON or EQUIVALENCE
- If I want a variable saved, it gets SAVE explicitly declared
- 'module' and 'file' are synonyms
- All modules contain a routine which spits out their CVS information
- USE statements go at module level, not procedure level
Of course, all of these are adjusted to fit in with the coding style of
the program I'm modifying - I don't rewrite entire F77 codes just to get
rid of COMMON blocks. However, I will make sure that any new sections I
add don't add new COMMON blocks (with one exception for tricking OpenMP
into scoping variables more conveniently).
I quite like array syntax, and FORALL when possible (although I know
that it's possible to write hideous expressions with them). I appreciate
that they can be bottlenecks (along with assumed shape arrays), but
during development that's not so important. Better to get clean code
running, and do clever things on the specific bottlenecks later.
I'm undecided on ONLY clauses. If an imported module is very large, I
can certainly see them being very useful. However, I'd tend to the
position that such a module should probably be split up a bit.
Personally, I don't like preprocessors, since it can make debugging
tricky (i.e. finding out what the compiler actually saw), although I can
see that they can be useful too. Similarly, I dislike INCLUDE - I'd
rather USE a module. Again, I know that INCLUDE can let you do generic
programming, even in the absence of templates.
That's my tuppenworth, at least ;-)
Richard
| |
| David Flower 2006-09-01, 7:00 pm |
|
Stanislaus wrote:
> Hello,
>
> Are there any code styles for Fortran? Official or not. And what do you
> prefer?
1. Never use extensions when there is a satisfactory standand
alternative.
2. If you have to use an extension, encapsulate it.
3. Failing the above, comment it in a manner that can be easily located
in a global search
Dave Flower
| |
| beliavsky@aol.com 2006-09-01, 7:00 pm |
| Richard Edgar wrote:
<snip>
> - EXITs always go to a named label
May I ask why you do this? Usually a simple EXIT does what I want,
sending the program to the first line after the end of the inner-most
block. If I want to do something else, such as EXIT multiple loops, I
use a named label.
| |
| Jim Klein 2006-09-01, 7:00 pm |
| nospam@see.signature (Richard Maine) wrote:
>Jim Klein <jameseklein@earthlink.net> wrote:
>
>
>I have to disagree with that, because I've seen too many codes written
>with exactly that rule. This results in code like
>
> c Assign 3 to x
> x = 3
>
>or even worse
>
> c Assign 3 to x
> x = 4
>
>Yes, I know that you meant useful comments. But since "useful" is a
>subjective judgement, that part gets dropped and you end up with rules
>like "have at least one comment line for every line of code."
>Bureaucracies (like the one I work for) are fond of simple objective
>criteria like that - the are so much easier than thinking. The fact that
>this completely misses the point of the rule in the first place is, I'm
>afraid, lost. Yes, it does happen that such rules get applied like that;
>I've seen it.
Excellent point. You could have ever other line a comment and have
them 100% useless. :-)
James E. Klein
jameseklein@earthlink.net
Engineering Calculations
http://www.ecalculations.com
ecalculations@ecalculations.com
Engineering Calculations is the home of
the KDP-2 Optical Design Program
for Windows and (soon) MAC OSX
Free KDP-2 (DEMO) downloadable!
1-818-507-5706 (Voice and Fax)
| |
| Richard Edgar 2006-09-01, 7:00 pm |
| beliavsky@aol.com wrote:
> Richard Edgar wrote:
>
>
> May I ask why you do this? Usually a simple EXIT does what I want,
> sending the program to the first line after the end of the inner-most
> block. If I want to do something else, such as EXIT multiple loops, I
> use a named label.
Because I tend to prefer things to be absolutely explicit. I also use
more parentheses than I strictly need.
Richard
| |
| Richard Maine 2006-09-01, 7:00 pm |
| <beliavsky@aol.com> wrote:
> Richard Edgar wrote:
>
>
> May I ask why you do this? Usually a simple EXIT does what I want,
> sending the program to the first line after the end of the inner-most
> block. If I want to do something else, such as EXIT multiple loops, I
> use a named label.
I don't know about the other Richard, but one reason I do it is for
clarity. An unadorned "exit" is too easy to misunderstand. For example,
it can be misread as a synonym for "return". To me, an unadorned "exit"
begs for the question "exit what?" I happen to know the answer, but only
because I spend a lot of tiem with the language.
For that matter, the unadorned exit is responsible for a bit of a hack
in future enhancements (I think in the f2008 drafts). The fact that a
hack was needed was likely what delayed a reasonably often requested
feature that long - the feature didn't add "cleanly". Namely, the new
feature is to allow EXIT to exit constructs other than DO. But if you
add that feature without a secial hack, then it becomes an
incompatibility with existing code that has, for example, an unadorned
EXIT in an IF construct in a DO. The proposed special case treats DO
differently than other constructs for the unadorned exit.
I was thinking of making another comment about Richard Edgar's post, but
I'll throw it in here instead of separately. I agree with everything in
his post (including the EXUT thing) - so much so that I could imagine
having written it. But nope, that's a different Richard.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Dushan Mitrovich 2006-09-01, 7:00 pm |
| Brooks Moses <bmoses-nospam@cits1.stanford.edu> wrote:
>Richard Maine wrote:
>
> And, not to reopen the old argument too far, but in my opinion it's at
> least as important to write code that's comprehensible. I won't go so
> far as to say that good code shouldn't need comments at all, but I do
> think that "per line of code" is rather the wrong dimension of unit to
> measure it with -- lines of code, as such, should be clear enough to
> never need comments. Equations, algorithms, complex data structures,
> information flow, those on the other hand often do need comments, to
> explain where they came from and sometimes why they were chosen. But
> those comments are almost never at the line-of-code level.
>
> - Brooks, who tends to put equation derivations and literature citations
> in his comments every so often. When I look at my code three years from
> now, I want to be able to check to make sure the math was right!
A big AMEN to this - exactly what I do; painful headscratching at my own
code has taught me this. Another thing I include in the comments is the
set of assumptions used. It has always bugged me to see code written as
interminable strings, with no spaces around the '=' and '+/-' signs,
terms not grouped for readability, and no separation between functional
sections.
- Dushan Mitrovich
| |
| Richard Edgar 2006-09-01, 7:00 pm |
| Richard Maine wrote:
> I was thinking of making another comment about Richard Edgar's post, but
> I'll throw it in here instead of separately. I agree with everything in
> his post (including the EXUT thing) - so much so that I could imagine
> having written it. But nope, that's a different Richard.
I'm flattered ;-)
Richard
| |
| Roman S. 2006-09-01, 7:00 pm |
| Richard Edgar wrote:
> Some other personal style points:
> - Everything goes into MODULEs, to make sure interfaces are explicit
> - All modules have an unqualified PRIVATE statement
> - All functions and subroutines have INTENT declared on their arguments
> - I use REAL with KIND specified (according to a PARAMETER in a "Kinds"
> module), not DOUBLE PRECISION
> - Functions don't have side-effects, and don't modify their arguments
> However, I don't count WRITE(*,*) and STOP as side effects in this. I
> basically try to make functions PURE, but those exceptions prevent me
> declaring them as such
> - EXITs always go to a named label
> - No GOTO, COMMON or EQUIVALENCE
> - If I want a variable saved, it gets SAVE explicitly declared
> - 'module' and 'file' are synonyms
> - All modules contain a routine which spits out their CVS information
> - USE statements go at module level, not procedure level
Hi Richard,
I agree with your points. However, I prefer to have the USE statement
at the procedure level. This way I know exactly what gets USEd where.
For example:
!---------------------------------
module mod_a
!! I don't like the following statement because it doesn't tell me
!! what I'm using from mod_b, and where I'm using it.
! USE mod_b
contains
subroutine sub1()
USE mod_b, only: s1 !!
implicit none
call s1()
return
end subroutine sub1
!------------------------------
subroutine sub2()
USE mod_b, only: s2 !!
implicit none
call s2()
return
end subroutine sub2
end module mod_a
!---------------------------------
Roman
| |
| Thomas Koenig 2006-09-02, 3:59 am |
| Brooks Moses <bmoses-nospam@cits1.stanford.edu> wrote:
>- Brooks, who tends to put equation derivations and literature citations
>in his comments every so often. When I look at my code three years from
>now, I want to be able to check to make sure the math was right!
Good move. Trying to make sense of (for example) finite element
shape functions without a reference isn't fun, as I know...
Addittionally: For maximum maintainability, functions and
subroutine interfaces (including COMMON and module use) should be
commented so extensively that the function or subroutine could be
recreated without reading the actual code.
| |
| Jan Vorbrüggen 2006-09-04, 3:59 am |
| > C Number of points for a dropped goal
> X = 3
It is my opinion that code shouldn't contain unnamed constants. In fact,
very often what you thought was a constant ends up being variable, if only
at compile time 8-). The only exception I would generally make is for the
usual off-by-one thing, including neighbourhoods of points in an array.
Jan
| |
| beliavsky@aol.com 2006-09-05, 10:00 pm |
| Stanislaus wrote:
> Hello,
>
> Are there any code styles for Fortran? Official or not. And what do you
> prefer?
The message below from the comp.lang.fortran archives explains what NOT
to do.
From
senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!spool.mu.edu!howland.reston.ans.net!gatech2!swrinde!cs.utexas.edu!utnut!nott!cu23.crl.aecl.ca!usenet
Tue Dec 12 12:52:20 1995
Newsgroups: comp.lang.fortran
Path:
senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!spool.mu.edu!howland.reston.ans.net!gatech2!swrinde!cs.utexas.edu!utnut!nott!cu23.crl.aecl.ca!usenet
From: glenr@cu71.crl.aecl.ca (Glen Reesor)
Subject: Fortran Coding Style for the Modern Programmer
X-Nntp-Posting-Host: cu71.crl.aecl.ca
Message-ID: <DIx7uv.Jn2@cu23.crl.aecl.ca>
Sender: usenet@cu23.crl.aecl.ca (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
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.
| |
| David Flower 2006-09-06, 4:00 am |
|
beliavsky@aol.com wrote:
> Stanislaus wrote:
>
> The message below from the comp.lang.fortran archives explains what NOT
> to do.
>
> From
> senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!spool.mu.edu!howland.reston.ans.net!gatech2!swrinde!cs.utexas.edu!utnut!nott!cu23.crl.aecl.ca!usenet
> Tue Dec 12 12:52:20 1995
> Newsgroups: comp.lang.fortran
> Path:
> senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!usenet.eel.ufl.edu!spool.mu.edu!howland.reston.ans.net!gatech2!swrinde!cs.utexas.edu!utnut!nott!cu23.crl.aecl.ca!usenet
> From: glenr@cu71.crl.aecl.ca (Glen Reesor)
> Subject: Fortran Coding Style for the Modern Programmer
> X-Nntp-Posting-Host: cu71.crl.aecl.ca
> Message-ID: <DIx7uv.Jn2@cu23.crl.aecl.ca>
> Sender: usenet@cu23.crl.aecl.ca (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
> 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.
16. is unfair, blank lines only became standard with F77, and if the
deck is dusty enough...
Dave Flower
PS Ever seen the following:
IF ( N .EQ. 0 ) N = 0
(It actually makes perfect sense)
| |
| Brooks Moses 2006-09-06, 7:01 pm |
| beliavsky@aol.com wrote, quoting glenr@cu71.crl.aecl.ca (Glen Reesor):
> 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.
Heh. Guilty, though just in code for my own use. I do ameliorate the
problem a bit by skipping every odd line in the file-reading routine,
and using those to put variable names in the file so I can at least read
it easily (and have a template for where the columns go).
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Richard Edgar 2006-09-06, 7:01 pm |
| Brooks Moses wrote:
> beliavsky@aol.com wrote, quoting glenr@cu71.crl.aecl.ca (Glen Reesor):
>
> Heh. Guilty, though just in code for my own use. I do ameliorate the
> problem a bit by skipping every odd line in the file-reading routine,
> and using those to put variable names in the file so I can at least read
> it easily (and have a template for where the columns go).
You're not trying hard enough.... what you _should_ be doing is reading
everything in from standard input, because the 'normal' way to use your
huge, multiprocessor code is by typing in answers to questions posed at
runtime. That way, you can close down that 'every other line is the list
of variable names' loophole. Input files instantly become columns of
numbers, with the odd 'y' and 'n' thrown in for good measure! ;-)
Richard
| |
| beliavsky@aol.com 2006-09-17, 7:00 pm |
| Here are some guidelines I follow (1) and (2) or am thinking of
following in the future (3). These supplement other guidelines stated
in the thread.
(1) Pass assumed size arrays to procedures, and check that the sizes
are correct -- often a dimension of one array must match a dimension
of another.
(2) If a file unit is opened in a procedure, it should be closed there,
or the unit number should be passed back to the main program.
(3) Free resources as soon as possible. When an ALLOCATABLE array is no
longer needed, DEALLOCATE it. When an I/O unit is no longer used, CLOSE
it. Although allocatable arrays will be deallocated if they have
procedure scope and the procedure is exited, and also when a program
terminates, explicit deallocation
(a) makes clear which arrays are no longer being used
(b) could avoid an out-of-memory crash
(c) makes it possible to wrap a block of code in a loop, as I often
later want to do. In Fortran 95 one cannot ALLOCATE an array that has
already been ALLOCATEd unless it has been explicitly DEALLOCATEd.
| |
| Gary Scott 2006-09-17, 10:00 pm |
| beliavsky@aol.com wrote:
> Here are some guidelines I follow (1) and (2) or am thinking of
> following in the future (3). These supplement other guidelines stated
> in the thread.
>
> (1) Pass assumed size arrays to procedures, and check that the sizes
> are correct -- often a dimension of one array must match a dimension
> of another.
>
> (2) If a file unit is opened in a procedure, it should be closed there,
> or the unit number should be passed back to the main program.
>
No problem with the others, but this one can be problematic. One of my
applications has multple-semi-independent sub-programs (the main is just
a menu system for selecting the sub-programs (sub-programs meaning that
each could be standalone if it weren't for the menu system tying them
together). Other programs, have many nested layers of procedures that
all access the same database file. It could be written such that the
LFN is hidden, but sometimes it is more convenient to manipulate locally
rather than pass to a handler.
> (3) Free resources as soon as possible. When an ALLOCATABLE array is no
> longer needed, DEALLOCATE it. When an I/O unit is no longer used, CLOSE
> it. Although allocatable arrays will be deallocated if they have
> procedure scope and the procedure is exited, and also when a program
> terminates, explicit deallocation
> (a) makes clear which arrays are no longer being used
> (b) could avoid an out-of-memory crash
> (c) makes it possible to wrap a block of code in a loop, as I often
> later want to do. In Fortran 95 one cannot ALLOCATE an array that has
> already been ALLOCATEd unless it has been explicitly DEALLOCATEd.
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
Why are there two? God only knows.
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
|
|
|
|
|