Writing robust and “modern” Fortran code

Question

In some scientific environments, you often cannot go without FORTRAN as most of the developers only know that idiom, and there is lot of legacy code and related experience.

Answer 1

I'm in a rather hurry, so forgive me if I'm making this answer in the form of checkpoints instead of reasonable sentences.

• try adhering to the standard (Fortran is a standardized language, and by adhering to standard language features, and avoiding vendor specific extensions, you'll have a portable between platforms program, for which you can be sure the compiler will give no problems). I don't know where I downloaded my copy, but I'm pretty sure you can download the latest draft (beware; many features of fortran 2008 or 2003 for that matter are still not implemented in the currect compiler, although many are almost there nowadays ... Cray being one) from J3's page
• for all questions regarding the above, I heartily recommend comp.lang.fortran usenet group - not only does it have some very knowledgeable people there (for example. mr. Richard Maine ... will probably be willing to answer any standard compliance questions you may ask, with much detail, if asked nicely ... same goes for many others) but it also has people who've worked on large scale problems and will certanly know and be willing to give advice on your subject
• books - in addition to all of the already mentioned (Metcalf, Reid and Cohen's book also has my recommendation, also "Fortran 2003 handbook" by Maine and others ...), try finding yourself a copy of Stephen J. Chapman's "Fortran 95/2003 for scientists and engineers" ... takes a little too confident stand on some topics, but still, overall a very nice book, with many "good programming practices" mentioned)
• also, don't know if you've comed across this one "Object oriented programming via Fortran 90/95"

---

Some comments on your text:

( This may all seem "evident" modern programming assumptions, but in a legacy fortran world, most of these are big changes in the typical programmer workflow )

Even in a modern fortran world, some of these assumptions are questionable ... remember, fortran programmers are not programmers (I'm repeating this in condensed form; I've already written this on this forum so many times) but engineers, scientists and so on. To them (us?) code is not a goal, but merely a tool ... to professional programmers code is everything; they have nothing "beyond it" ... therefore, they cherish it so much. To us engineers, it is merely a means of getting the result we want ... with that in mind, although good programming practices pay later, do not necessary insist on them where there is no obvious need for them.

The goal with all that is to have trustworthy, maintainable and modular code. Whereas, in typical fortran, modularity is often not a primary goal, and code is trustworthy only if the original developer was very clever, and the code was not changed since then ! (i'm a bit joking here, but not much)

Somebody once said, and you wouldn't believe how true it is:
"There is nothing more permanent than a temporary fix".

Any good URL, advice, reference paper/books on the subject?

Given several above.

Also, while writing this answer, I see High Perf. Mark posted a very nice answer, with which I mostly agree ... it goes a little more into detail about standard adhering.

Also, my recommendation would be to definitely post this question also on comp.lang.fortran ... I gather you can get much more quality answers there, then in here (I believe there isn't more then 20 or so fortran programmers on whole of stackoverflow).

There was a set of code writing guidelines published freely by some european union commitee; they would be very useful as part of this answer, but unfortunatelly, I cannot find them in my quick google search, and haven't got the time to look extensively. Try searching on the topic ... maybe you'll have better luck.