My philosophy

I have been programming in FORTRAN since the summer of 1966, so I
thought that others might be interested in (or provoked by) my
programming philosophy. So here are some pointer themes.

1) Know the standard; many problems are caused simply by programmers
being unaware of the standard.

2) Even if a standard permits something, it is not necessarily good
practice; an example is neglecting to put a RETURN statement in a
sub-progam, letting the END statement do the work. This confuses two
themes (pass control to calling routine which is an executable
statement, and this is the last statement of this routine, which is
not), and suggests woolly thinking by the programmer.

3) Never use an extension when there is a perfectly satisfactory
standard method of doing something; on the same theme, don't use a
FORTRAN 90 peculiarity if you can do it equally well in FORTRAN 77.
Please understand, I am not saying don't use FORTRAN 90 constructs, I
am merely objecting to programmers who use such constructs to show how
clever they are, not to produce good code.

4) If you have to use extensions, try to encapsulate them; in the
future, some poor programmer is going to have to convert the program to
a compiler that does not support the extension, and would prefer to
have to modify one site in the program, not forty two. And that poor
programmer might be you!

5) In the past, programs usually had to be modified to minimise memory
and/or run time. Nowadays, most code should be optimised for
readability and maintainability. There are few FORTRAN statements more
essential than the comment statement.


Well, that should be enough to start a discussion!

David Flower wrote:

> I have been programming in FORTRAN since the summer of 1966, so I
> thought that others might be interested in (or provoked by) my
> programming philosophy. So here are some pointer themes.

(snip, pretty much agreeing)

> 5) In the past, programs usually had to be modified to minimise memory
> and/or run time. Nowadays, most code should be optimised for
> readability and maintainability. There are few FORTRAN statements more
> essential than the comment statement.

While minimizing memory use isn't so important, I don't believe it
is wise to unnecessarily waste memory.

As an example, if a program can process one line at a time and generate
the desired result, don't read the whole file in, process it, and write
the results out.  There are cases where it is necessary,
and that is fine.

-- glen

Ah, soap box time. To the list of thoughts to keep in mind, add:

6) Put off coding until the programming is done. Do the programming at
some higher level of organization, outlining in some detail the
sequence of what must be done and methods used. Decide on the hierarchy
of subprograms, and produce documentation on how the whole thing and
each subprogram work. Debug at that level, then translate to code. If
you find that the last step is not just coding but involves too much in
the way or working out logic of events, then you need to go back up a
level to complete or revise the program. Spinning your wheels in trying
to get the code to cover all aspects of what possibilities must be
covered is a sure sign you haven't done the programming at a higher
level thoroughly yet. Fortran code shouldn't be the program, only the
compiler-readable form of the program.

RAR

David Flower wrote:
> I have been programming in FORTRAN since the summer of 1966, so I
> thought that others might be interested in (or provoked by) my
> programming philosophy. So here are some pointer themes.
> 1) Know the standard; many problems are caused simply by programmers
> being unaware of the standard.

Routinely compiling one's codes with several compilers and comparing
results helps one learn the standard.

> 2) Even if a standard permits something, it is not necessarily good
> practice; an example is neglecting to put a RETURN statement in a
> sub-progam, letting the END statement do the work. This confuses two
> themes (pass control to calling routine which is an executable
> statement, and this is the last statement of this routine, which is
> not), and suggests woolly thinking by the programmer.

What problems arise from not putting a RETURN statement before and END
statement?

> 3) Never use an extension when there is a perfectly satisfactory
> standard method of doing something; on the same theme, don't use a
> FORTRAN 90 peculiarity if you can do it equally well in FORTRAN 77.
> Please understand, I am not saying don't use FORTRAN 90 constructs, I
> am merely objecting to programmers who use such constructs to show
how
> clever they are, not to produce good code.

Can you cite a Fortran 90 construct that is overused?

Thanks for your comments.

<rest snipped>

Dick Russell wrote:
> Ah, soap box time. To the list of thoughts to keep in mind, add:
>
> 6) Put off coding until the programming is done. Do the programming at
> some higher level of organization, outlining in some detail the
> sequence of what must be done and methods used.

This is one reason I find IDL so useful. I use it to prototype a lot of my (
more
important) Fortran95 code to get all the design issues sorted before actuall
y writing
Fortran code.

cheers,

paulv

p.s. Of course, one can substitute "IDL" with matlab or any other similar to
ol of choice.

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

beliavsky@aol.com wrote:
> David Flower wrote:
> 
>
>
> Routinely compiling one's codes with several compilers and comparing
> results helps one learn the standard.
Make sure that strict standards conformance, including
bounds checking and argument list matching, is turned on.

>
> 
>
>
> What problems arise from not putting a RETURN statement before and END
> statement?
>
> 
>
> how
> 
>
>
> Can you cite a Fortran 90 construct that is overused?

Forcing things into array notation when simple DO
loops are clearer to the reader.

>
> Thanks for your comments.
>
> <rest snipped>
>

Dick Hendrickson

Dick Hendrickson wrote:
> beliavsky@aol.com wrote:
 
>
> Forcing things into array notation when simple DO
> loops are clearer to the reader.

I think element-wise array operations and intrinsic functions such as
DOT_PRODUCT, MATMUL, SUM, MINVAL, and PACK usually enhance readability
compared to loops, but I am wonder about complicated constructions
involving functions such as RESHAPE or SPREAD.

In article
<yzJie.226112$cg1.101713@bgtnsc04-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:
 
>
> Forcing things into array notation when simple DO
> loops are clearer to the reader.

Amen. In fact, this one is so overused (IMO) that you quite often hear
of people referring to this as converting from f77 to f90, as though the
DO loops somehow weren't valid f90, or even if valid, weren't "fully"
f90, or any of several other terms.

I'm a big "fan" of f90 as being an improvement over f77 (as any regular
reader of this newsgroup has probably figured out). But that doesn't
mean I am blind to issues like this.  Not all f77 DO loops were
"broken", and thus they don't all need to be "fixed".

There are times when the array notation is a great improvement - better
clarity, faster, more robust, whatever. But there are other times when
it isn't, and some people seem to like to just go in with a simple
global rule, without actually bothering to evaluate individual cases.

Reminds me much of the old GOTO thing, where I have seen people take
perfectly clear, simple, and well-structured code, and turn it into a
mess because of an obsession with removing GOTOs in order to "improve"
the structure. Sometimes the mess is bad enough that they don't even
manage to get the translation right, introducing bugs.

By the way, I don't see anything in the OP's post that I'd disagree with.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Richard E Maine wrote:
> By the way, I don't see anything in the OP's post that I'd disagree with.

...Well *I* do.

David Flower wrote:
> 2) Even if a standard permits something, it is not necessarily good
> practice; an example is neglecting to put a RETURN statement in a
> sub-progam, letting the END statement do the work. This confuses two
> themes (pass control to calling routine which is an executable
> statement, and this is the last statement of this routine, which is
> not), and suggests woolly thinking by the programmer.

My preference is NO return statement. END should mean both these themes. In
the event that 2 or more RETURNS would otherwise be required, I prefer to
have a labelled CONTINUE immediately prior to the END, and GOTO it. I find
this useful in debugging, since you can set a breakpoint at the end of the
routine and know you will catch it at the point of RETURNing, so allowing
all local variables to be examined before they dissappear when the stack is
popped. IMHO multiple RETURNs is (are?) at least as bad as multiple entry
points (alas, a habit I am still trying to break!)
--
Qolin

Email: my qname at domain
Domain: qomputing dot demon dot co dot uk

In article <1116416371.114554.258760@g47g2000cwa.googlegroups.com>,
"Dick Russell" <richard.russell@shawgrp.com> writes:

> Ah, soap box time. To the list of thoughts to keep in mind, add:
>
> 6) Put off coding until the programming is done. Do the programming at
> some higher level of organization, outlining in some detail the
> sequence of what must be done and methods used. Decide on the hierarchy
> of subprograms, and produce documentation on how the whole thing and
> each subprogram work. Debug at that level, then translate to code.

Right.  As Jerry Leichter proclaimed in his First Law of Computing: "If
you don't know how to do it, you don't know how to do it on a computer".