Professional programmers' coding conventions for Fortran

Hi,

reading Fortran code on the Internet, it seems to me that old FORTRAN 77
sources use capital letters for Fortran keywords (e.g.: PROGRAM, REAL,
etc.). Instead, for Fortran 9x code, from what I've looked at, I see a
lot of codes using all capital letters for keywords, but some codes also
uses all lower case (e.g.: program, implicit none, ...).

Now, I'd like to know what is the reccommended/preferred Fortran coding
convention for new Fortran programs: (1) always use lower-case (both for
identifiers and keywords), or (2) use lower-case for identifiers (with
underscore to seperate the single words building up the whole
identifier) and upper-case for keywords?

Moreover, what about tab stops for indentation? In C/C++ I think a
common rule is to use 4 or 8 blanks for a tab, while I see that Fortran
codes uses 2 or maximum 3 blanks for a tab. Is this right?

Last question about identifiers: recent C++, Java, C#, etc. code use
Pascal-casing (MyIdentifier) or Camel-casing (myIdentifier) for
identifiers, while all Fortran sources I read use "underscore lower-case
style" : my_identifier. Is there any reason for this identifier rule?
Any reccomendation from Fortran standard committee? Or "historical"
reasons?

Thanks in advance,

Ciao,
Dan

Danguard wrote:
> Hi,
>
> reading Fortran code on the Internet, it seems to me that old FORTRAN 77
> sources use capital letters for Fortran keywords (e.g.: PROGRAM, REAL,
> etc.). Instead, for Fortran 9x code, from what I've looked at, I see a
> lot of codes using all capital letters for keywords, but some codes also
> uses all lower case (e.g.: program, implicit none, ...).
>
> Now, I'd like to know what is the reccommended/preferred Fortran coding
> convention for new Fortran programs: (1) always use lower-case (both for
> identifiers and keywords), or (2) use lower-case for identifiers (with
> underscore to seperate the single words building up the whole
> identifier) and upper-case for keywords?

I tend to use lowercase for both; but I write intrinsic procedure names
in uppercase, to make it clear that there is something 'special' about
them. I also write optional arguments to intrinsic procedures in
uppercase, and keywords for open() (e.g., FILE=, FORM=) in uppercase. In
identifiers, I use underscore to separate words.

>
> Moreover, what about tab stops for indentation? In C/C++ I think a
> common rule is to use 4 or 8 blanks for a tab, while I see that Fortran
> codes uses 2 or maximum 3 blanks for a tab. Is this right?

I think I use 2 blanks, that being the default in the f90-mode on my
copy of emacs. Having 8 blanks would be a problem in Fortran, since --
unlike C/C++ -- we're limited in free source form to line lengths of 132
characters.

>
> Last question about identifiers: recent C++, Java, C#, etc. code use
> Pascal-casing (MyIdentifier) or Camel-casing (myIdentifier) for
> identifiers, while all Fortran sources I read use "underscore lower-case
> style" : my_identifier. Is there any reason for this identifier rule?
> Any reccomendation from Fortran standard committee? Or "historical"
> reasons?

Part of the reason for me lies in the fact that Fortran is
case-insensitive. Using a change in case as a word separator in
identifiers is problematical when the identifier can alternatively be
written all in lower or upper case: MYIDENTIFIER, myidentifier. So, I
use underscores instead, and use lowercase in all of my identifiers. The
one exception is when one of the words is a proper noun, in which case
it gets uppercased (e.g., eval_Legendre_polynomial).

One other style convention I adopt is the use of trailing underscores to
deal with default values of optional arguments. If I have an optional
argument foo, that requires a default value if it isn't specified, then
I use code of the form:

subroutine my_sub (foo)

integer, intent(in), optional :: foo

integer                       :: foo_

if(PRESENT(foo)) then
foo_ = foo
else
foo_ = <default value>
endif

<subsequent code references foo_ and not foo>

end subroutine my_sub

On a closing note, coding style is a pretty personal thing; find
something you're comfortable with, that's not too outlandish, and
then stick to it. I think the *most* important aspect of coding style,
especially in large programs, is that it be consistent.

cheers,

Rich

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]

One set of guidelines for Fortran 90 code is at http://www.meto.gov.uk/research/nw<..._standards.html


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==--
--
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 News
groups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =
---

Danguard wrote:

> Hi,
>
> reading Fortran code on the Internet, it seems to me that old FORTRAN 77
> sources use capital letters for Fortran keywords (e.g.: PROGRAM, REAL,
> etc.). Instead, for Fortran 9x code, from what I've looked at, I see a
> lot of codes using all capital letters for keywords, but some codes also
> uses all lower case (e.g.: program, implicit none, ...).

I use all lower case except for any parameters that I define. That indicates
to me (while programming / debugging) that these cannot be modified.
Fortran is case insensitive anyways.

>
> Now, I'd like to know what is the reccommended/preferred Fortran coding
> convention for new Fortran programs: (1) always use lower-case (both for
> identifiers and keywords), or (2) use lower-case for identifiers (with
> underscore to seperate the single words building up the whole
> identifier) and upper-case for keywords?

Create your own, but stick to it (for your own good) and document identifier
declarations well (for everyone's good).

>
> Moreover, what about tab stops for indentation? In C/C++ I think a
> common rule is to use 4 or 8 blanks for a tab, while I see that Fortran
> codes uses 2 or maximum 3 blanks for a tab. Is this right?

I use emacs for writing code. And manually indent the first line in the
source file with 6 blanks (following an old convention, which is not
necessary, but I like because it looks neater that way - you need to have
space for format labels, etc. anyways), and emacs f90 mode + TAB take care
of the rest of the indentation.

>
> Last question about identifiers: recent C++, Java, C#, etc. code use
> Pascal-casing (MyIdentifier) or Camel-casing (myIdentifier) for
> identifiers, while all Fortran sources I read use "underscore lower-case
> style" : my_identifier. Is there any reason for this identifier rule?
> Any reccomendation from Fortran standard committee? Or "historical"
> reasons?

Fortran identifiers are case insensitive. Therefore, "MyIdentifier" and
"myIdentifier" are identical. There is no "rule" as such, but is a
recognition of a need to provide unique identifier names.

In article <MPG.1c0a8edf79fc8e2a989a42@powernews.libero.it>,
Danguard  <danguard_robot@hotmail.com> wrote:

>reading Fortran code on the Internet, it seems to me that old FORTRAN 77
>sources use capital letters for Fortran keywords (e.g.: PROGRAM, REAL,
>etc.).

All 3 things you cite: caps, tab widths, and StudlyCaps names verses
not_studly names, are choices. In other languages, you can't choose to
put keywords in caps, but the other 2 are still choices. All C/C++ GNU
code and most Linux code uses tab widths of 3 and not_studly names --
contrary to what you've seen. Needless to say, coding standards make
wildly different recommendations for these options, but I have never
worked on a project that used wide tab widths. (And I don't think
professional vs. non-professional makes much difference; most big
non-professional projects have coding conventions, too.)

And in the Fortran world, most code uses lower-case keywords, unless
it's so old it had to be upper-case. Interestingly, not_studly (or
notstudly) names won out despite '_' being an extension (in the early
days.)

Now, if you want a funny example, the marketing people want our
company name spelled PathScale, but our company coding standards
prohibit StudlyCaps names in code! I guess the VP Marketing didn't
read the memo from Engineering...

-- greg

Danguard <danguard_robot@hotmail.com> writes:

> Now, I'd like to know what is the reccommended/preferred Fortran coding
> convention for new Fortran programs: (1) always use lower-case (both for
> identifiers and keywords), or (2) use lower-case for identifiers (with
> underscore to seperate the single words building up the whole
> identifier) and upper-case for keywords?

You really won't find universal agreement on things like this.  It is
a personal style choice.  Yes, you will find some groups gravitating
to common choices, but that isn't really the same thing as a
recommendation.

I mostly use all lower case because

1. It is easier to type than having to hit the shift key every few
letters.  Aggravated by the fact that my hands don't seem to
co-ordinate on that quite as well as they used to.  One of my
pretty common typos is to capitalize the first 2 letters of a
capitalized word instead of the first one.

2. It Matches My Use Of Normal English. I Don't Normally Type
English Like This (And I'm Finding It Darned Hard To Do Without
Typing SLowly And Deliberately - See Reason 1), So Why Should I
Do My Fortran Like This?

For multi-word identifiers, I'm not entirely consistent.  I most
often use underscores, but note that neither of the above 2 reasons
directly implies that.  Underscores also need the shift key, and I
don't use them in English.  One could argue for hyphens based on
the English usage, but that just doesn't "work" in Fortran; the
underscore looks sort of like a hyphen.

I used to use what you call Camel-casing (myIdentifier).  I hadn't
heard that term, but its derivation is obvious enough.  Much of my
reason for that was that f77 didn't allow underscores in names.  It
also didn't allow names longer than 7 characters, but that eventually
became a common enough extension that I adopted it.  (Underscores
were also common, but not quite as common quite as early).

But all of this is just rationalizing my personal style.  I can't
say it is necessarily a recommendation for others.


> Moreover, what about tab stops for indentation?...
> Is this right?

There is no "right".  I like to use just enough so that it stands
out clearly.  I find it distracting to indent too much (particularly
if the indentation levels nest very deeply).  One space just doesn't
stand out nearly well enough, but 2 is usually ok for me.  Certainly
3 is plenty.  This one is very personal.

> Any reccomendation from Fortran standard committee?

No way. The standard does have a few recommendations, but they tend
to be on technical matters.  It doesn't get within a mile of making
recommendations on things like this.

> Or "historical" reasons?

Considering that the language didn't even formally acknowledge
multiple cases until f90, the only choice that might be argued
as "historical" would be all caps for everything.  I happen to
personally find that one really ugly and distracting, but I'm
sure that there have been people on this newsgroup who felt
otherwise.

By the way, one of the more trvial "new" features of f2003 is that
it is the first version of the Fortran standard to actually
mandate that the compiler acccept both cases.  Before f90,
multiple cases were not even mentioned.  F90 made it optional
whether the compiler supported multiple cases, but did define
some requirements about how it had to work if the compiler did
so (namely the case-insensitivity of mosty things).  I'm not sure
that there was ever an f90 compiler that didn't support both cases.
F2003 finally just plain mandated what was already defacto as
a standard - that all compilers support it.

(I still haven't heard whether f2003 is yet officially published...
which probably means it isn't, though I place no bets either way.
Last I heard was something like "hopefully around the end of the
month"... but the month in question was October.)

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

Danguard wrote:
> Hi,
>
> reading Fortran code on the Internet, it seems to me that old FORTRAN 77
> sources use capital letters for Fortran keywords (e.g.: PROGRAM, REAL,
> etc.). Instead, for Fortran 9x code, from what I've looked at, I see a
> lot of codes using all capital letters for keywords, but some codes also
> uses all lower case (e.g.: program, implicit none, ...).
>
> Now, I'd like to know what is the reccommended/preferred Fortran coding
> convention for new Fortran programs: (1) always use lower-case (both for
> identifiers and keywords), or (2) use lower-case for identifiers (with
> underscore to seperate the single words building up the whole
> identifier) and upper-case for keywords?

My main goal in this respect is to write commented code that is understandab
le. A good
test is to give a section of your code to someone who is unfamiliar with For
tran (of
whatever flavour) and ask them if they can deduce what it is you're trying t
o do. If they
can then there's a very good chance that future maintainers of your code wil
l also be able
to do so (and modify it as required when new techniques/algorithms/data come
 along). A
good deal of making the code understandable has less to do with naming conve
ntions than
with good design, but readable code can only help.

How you achieve all this (upper case, lower case, embedded caps, etc etc.) i
s up to you -
your own aesthetics come into play here I reckon. Plenty of computer-y books
 have coding
style recommendations - get some from your library and pick one that you lik
e the look of.
(Caveat: if you get a reference that says you shouldn't do it any other way 
that what they
recommend, discontinue use. :o)  I'm sure there are even cognitive-type stud
ies that
recommend styles based upon its readability.

> Moreover, what about tab stops for indentation? In C/C++ I think a
> common rule is to use 4 or 8 blanks for a tab, while I see that Fortran
> codes uses 2 or maximum 3 blanks for a tab. Is this right?

I dislike tabs since they're interpreted differently across applications. An
d they're a
waste of space (IMO). I prefer 2 spaces for indentations. Some people like 4
. Or 3. I have
a lot of (other people's) code that uses none. <shudder>  I don't use that c
ode much.

> Last question about identifiers: recent C++, Java, C#, etc. code use
> Pascal-casing (MyIdentifier) or Camel-casing (myIdentifier) for
> identifiers, while all Fortran sources I read use "underscore lower-case
> style" : my_identifier. Is there any reason for this identifier rule?
> Any reccomendation from Fortran standard committee? Or "historical"
> reasons?

I used to do "my_identifier" but now I favour "My_Identifier", and sometimes
 even
"MyIdentifier". Same dog, different leg. (The only reason I usually use the 
latter is when
I bump into the 31-character limit on names. Being a verbose programmer, it 
happens to me
a lot. :o)  Fortran statements and parameter name I always do in uppercase. 
No particular
reason (as far as I can remember), I just like the way it looks.

cheers,

paulv

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

Richard E Maine wrote:
>
> junk snniped

OP asked for coding conventions not for professional babble!

tes <tora@cloudy.com> writes:

> Richard E Maine wrote: 
>
> OP asked for coding conventions not for professional babble!

That's ok.  I didn't ask for anything at all from you.  I see
that it didn't stop you either. :-(

On the other hand, while I rambled a bit in the process, I also
specifically answered some direct questions that the OP asked,
such as his
 

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

> On the other hand, while I rambled a bit in the process, I also
> specifically answered some direct questions that the OP asked,
> such as his

I think the reasons behind a convention are at least as important
as the convention itself.  Some bit of rambling is needed.

I don't believe that majority rule is the best way to select
a coding standard.  I happen not to like some popular
conventions, and the fact that many people do doesn't
convince me to change.

-- glen