Learn how to write technical applications in a modern object-oriented approach, using Fortran 90 or 95. This book will teach you how to stop focusing on the traditional procedural abilities of Fortran and to employ the principles of object-oriented programming to produce clear, highly efficient executable codes. In addition to covering the OOP methodologies the book also covers the basic foundation of the language and good programming skills. The author highlights common themes by using comparisons with Matlab and C++ and uses numerous cross-referenced examples to convey all concepts quickly and clearly. Complete code for the examples is included on the book's web site.
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. And frankly, there are not many other cross-platform options for high performance programming (C++ would do the task, but the syntax, zero-starting arrays, and pointers are not compatible with some people).
So, let's assume a new project must use Fortran 90, but I want to build the most modern software architecture out of it, while being compatible with most recent compilers (Intel ifort, but also including the Sun/HP/IBM compilers)
So I'm thinking of imposing stuff that is widely known as common good sense, but not yet a standard in my environment:
implicit none, etc.
#ifdef DEBUG) with more checks and all possible Intel compiler checks possible (array bounds, subroutine interfaces, etc.)
The goal with all that is to have trustworthy, maintainable and modular code. Whereas, in lot of legacy codes, re-usability was not a important target.
I searched around for references about object-oriented Fortran, programming-by-contract (assertions/preconditions/etc.), and found only ugly and outdated documents, syntaxes and papers done by people with no large-scale project involvement, and dead projects.
Any good URLs, advice, reference paper/books on this subject?
I'm in a rather hurry, so forgive me if I'm making this answer in the form of checkpoints instead of reasonable sentences.
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.