Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h2>Legacy Fortran Soapbox</h2> <p>I helped maintain/improve a legacy Fortran code base for quite a while and for the most part think <strong>sixlettervariables</strong> is on the money. That advice though, tends to the technical; a tougher row to hoe is in implementing "good practices".</p> <ul> <li>Establish a required coding style and coding guidelines.</li> <li>Require a code review (of more than just the coder!) for anything submitted to the code base. (Version control should be tied to this process.)</li> <li>Start building and running unit tests; ditto benchmark or regression tests.</li> </ul> <p>These might sound like obvious things these days, but at the risk of over-generalizing, I claim that most Fortran code shops have an entrenched culture, some started before the term "software engineering" even existed, and that over time what comes to dominate is "Get it done now". (This is not unique to Fortran shops by any means.)</p> <h2>Embracing Gotchas</h2> <p>But what to do with an already existing, grotty old legacy code base? I agree with Joel Spolsky on rewriting, <a href="http://www.joelonsoftware.com/articles/fog0000000069.html" rel="noreferrer" title="Things You Should Never Do, Part I">don't</a>. However, in my opinion <strong>sixlettervariables</strong> does point to the allowable exception: <em>Use software tools to transition to better Fortran constructs.</em> A lot can be caught/corrected by code analyzers (<a href="http://www.forcheck.nl/" rel="noreferrer" title="FORCHECK, or FORCHK">FORCHECK</a>) and code rewriters (<a href="http://www.polyhedron.com/pf-plusfort0html" rel="noreferrer" title="plusFORT is a Fortran code toolset">plusFORT</a>). If you have to do it by hand, make sure you have a pressing reason. (I wish I had on hand a reference to the number of software bugs that came from fixing software bugs, it is humbling. I think some such statistic is in <a href="http://rads.stackoverflow.com/amzn/click/0131774298" rel="noreferrer">Expert C Programming</a>.)</p> <p>Probably the best offense in winning the game of Fortran gotchas is having the best defense: Knowing the language fairly well. To further that end, I recommend ... books!</p> <h2>Fortran Dead Tree Library</h2> <p>I have had only modest success as a "QA nag" over the years, but I have found that education does work, some times inadvertently, and that one of the most influential things is a reference book that someone has on hand. I love and highly recommend</p> <p><strong><a href="http://www.mhhe.com/engcs/general/chapman/" rel="noreferrer" title="Best Fortran 77/90/95 textbook">Fortran 90/95 for Scientists and Engineers</a></strong>, by Stephen J. Chapman</p> <p>The book is even good with Fortran 77 in that it specifically identifies the constructs that shouldn't be used and gives the better alternatives. However, it is actually a textbook and can run out of steam when you really want to know the nitty-gritty of Fortran 95, which is why I recommend</p> <p><strong><a href="http://rads.stackoverflow.com/amzn/click/0198505582" rel="noreferrer">Fortran 90/95 Explained</a></strong>, by Michael Metcalf &amp; John K. Reid</p> <p>as your go-to reference (sic) for Fortran 95. Be warned that it is not the most lucid writing, but the veil will lift when you really want to get the most out of a new Fortran 95 feature.</p> <p>For focusing on the issues of going from Fortran 77 to Fortran 90, I enjoyed</p> <p><strong><a href="http://portal.acm.org/citation.cfm?id=162262" rel="noreferrer">Migrating to Fortran 90</a></strong>, by Jim Kerrigan</p> <p>but the book is now out-of-print. (I just don't understand O'Reilly's use of <a href="http://safari.oreilly.com/" rel="noreferrer">Safari</a>, why isn't every one of their out-of-print books available?)</p> <p>Lastly, as to the heir to the wonderful, wonderful classic, <a href="http://rads.stackoverflow.com/amzn/click/020103669X" rel="noreferrer">Software Tools</a>, I nominate</p> <p><strong><a href="http://rads.stackoverflow.com/amzn/click/0824708024" rel="noreferrer" title="Classical FORTRAN is also on Google Books">Classical FORTRAN</a></strong>, by Michael Kupferschmid</p> <p>This book not only shows what one can do with "only" Fortran 77, but it also talks about some of the more subtle issues that arise (e.g., should or should not one use the EXTERNAL declaration). This book doesn't exactly cover the same space as "Software Tools" but they are two of the three Fortran programming books that I would tag as "fun".... (<a href="http://www.seas.gwu.edu/~kaufman1/FortranColoringBook/ColoringBkCover.html" rel="noreferrer" title="The Fortran Coloring Book">here's the third</a>).</p> <h2>Miscellaneous Advice that applies to <em>almost</em> every Fortran compiler</h2> <ul> <li>There is a compiler option to enforce IMPLICIT NONE behavior, which you can use to identify problem routines without modifying them with the IMPLICIT NONE declaration first. This piece of advice won't seem meaningful until after the first time a build bombs because of an IMPLICIT NONE command inserted into a legacy routine. (What? Your code review didn't catch this? ;-)</li> <li>There is a compiler option for array bounds checking, which can be useful when debugging Fortran 77 code.</li> <li>Fortran 90 compilers should be able to compile almost all Fortran 77 code and even older Fortran code. Turn on the reporting options on your Fortran 90 compiler, run your legacy code through it and you will have a decent start on syntax checking. Some commercial Fortran 77 compilers are actually Fortran 90 compilers that are running in Fortran 77 mode, so this might be relatively trivial option twiddling for whatever build scripts you have.</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload