Fortran Refactoring
Fortran into the Future
This blog is about software engineering in academic contexts. We see a lot of "styles"* of code. Improving these, through refactoring (re-writing to have the same function, but an improved form), training academics who write and maintain them, and offering libraries and code snippets that address common function well, is a big part of our role.
*styles is in scare-quotes for a reason. Sometimes style is just an excuse for doing it wrong.
In STEM disciplines (at least the first 3 letters of it), Fortran code is pretty common, and some of it is the opposite of pretty. Modern approaches like modularity of design, well-defined interfaces, use of types and Object Oriented features, are often mysterious and underused.
There's two choices on how to handle these old* (see below) codes.
*old: synonyms 'ancient', 'decrepit', 'mature', 'venerable', 'familiar', 'long-lived'. Take your pick. Sometimes something is old because nobody bothered to renew it, sometimes it is old because it works.
Choice 1) Abandon them. Rewrite them in a cool new language (Rust! Julia!). Get rid of the cruft and the dust and make something new and better.
Choice 2) Refactor them. Take advantage of the experience that has gone into them and make them better slowly but surely.
These posts plan to talk about the second approach. Sometimes small improvements can greatly increase robustness, utility and our quality-of-life when we have to deal with these codes, without introducing new bugs and regressions or re-inventing the wheel.
Refactoring is an idea few seem to bother with, and even those who want to do it struggle to find any time or funding for the work!
So let's discuss some of the nice features of Fortran, with half-an-eye on the less well know bits, especially those which help us to 'patch-in' the new feature cheaply. These kinds of refactors can reward the effort many times over, without the time and risk of a full rewrite.
A List (hopefully a growing one)
Links TBA once the corresponding post is ready
Types and Component Selection - use the type system for clarity and robustness
Common blocks - strategies for getting rid
Explicit Interfaces - a step towards modularity
No comments
Add a comment
You are not allowed to comment on this entry as it has restricted commenting permissions.