Further Reading: Reading FORTRAN 77

Resources for reading legacy Fortran fluently and preparing to modernize it. Sources are tagged Tier 1 (works we are confident exist and recommend) and Tier 2 (real and worth seeking, but confirm the current edition/URL yourself). Because this chapter is about old code, some of the best references are the "legacy features" appendices of otherwise-modern books, and the compiler documentation that tells you which features are obsolescent, deleted, or merely tolerated.

The language references (with the legacy features documented)

• Metcalf, Reid, and Cohen, Modern Fortran Explained (Oxford University Press). The definitive language reference, and — importantly for this chapter — it documents the obsolescent and deleted features (arithmetic IF, computed GOTO, statement functions, COMMON, EQUIVALENCE, ENTRY, Hollerith) precisely, with the standard's own status labels. When you need to know exactly what a legacy construct means, this is the book. Tier 1.
• Stephen Chapman, Fortran for Scientists and Engineers (McGraw-Hill). A teaching text that keeps a clear "this is obsolete, here is the modern replacement" stance throughout and collects the legacy constructs in dedicated sections — close in spirit to how this chapter treats them. Tier 1.

The standards (primary sources)

• The current ISO Fortran standard (ISO/IEC 1539-1). The 2018 (and now 2023) standard carries an annex listing obsolescent features — the committee's own on-notice list of constructs to avoid, which reads as a near-exact table of contents for this chapter. Tier 1.
• The FORTRAN 77 standard (ANSI X3.9-1978). The original definition of the dialect you are learning to read; historically interesting and occasionally the only authority on a genuine corner case. Copies are harder to obtain than the modern standard; seek it only when a subtlety demands the primary source. Tier 2.

The compiler's own legacy documentation

• The GCC / gfortran manual — the "Fortran Dialect" and legacy pages. Documents exactly what -std=legacy accepts, how fixed-form is parsed, and which extensions gfortran tolerates. When an old file compiles under -std=legacy but not -std=f2018, this manual tells you which feature is the reason. Tier 1.
• The gfortran "Mixed-Language Programming" and obsolescent-warning notes. Turning on standard warnings (-std=f2018 on a legacy file) makes the compiler name each obsolete construct it finds — a fast way to inventory what a code will need modernized. Tier 2.

On legacy code as an engineering problem

• Martin Fowler, Refactoring: Improving the Design of Existing Code (Addison-Wesley). Not Fortran-specific, but the canonical treatment of the discipline this whole part teaches: changing the structure of working code without changing its behavior, in small verified steps. The source of this chapter's epigraph. Tier 1.
• Michael Feathers, Working Effectively with Legacy Code (Prentice Hall). The standard reference on getting a test harness around untested legacy code so you can change it safely — the exact discipline of this chapter's second case study, in a language-agnostic form. Tier 1.

The community and modernization tools

• fortran-lang.org — the "Migrating from older Fortran" and best-practices material. The modern Fortran community's practical guidance on reading and updating old code, kept current as the tooling evolves. Tier 1.
• Automatic conversion tools (e.g., fixed-to-free-form converters, findent, fprettify). Utilities that mechanically reformat fixed-form to free-form and re-indent legacy source — useful for the cosmetic first steps of modernization, though never for the semantic ones. Confirm the current tool and its limits before trusting it on production code. Tier 2.

Suggested order

1. Skim the obsolescent-features annex of the current standard (or Metcalf/Reid/Cohen's summary of it): in ten minutes it gives you the whole map of what "legacy" means, formally.
2. Read the gfortran legacy-dialect pages just far enough to understand -std=legacy, then compile this chapter's plate-legacy.f and confirm the ramp output.
3. Keep Metcalf/Reid/Cohen at hand as the authority when a specific old construct puzzles you.
4. Read Fowler (and, for the testing angle, Feathers) before Chapter 18 — the why and how of safe refactoring is the intellectual backbone of the modernization you are about to do.