Our initiative to publish the "Fortran-lang Top 10 Recommendation for Fortran modernization", is it really new or even feasible?

Advocacy
11

Hello from the Codee team!

First, thank you for your feedback on our “Top 10 Recommendations for Fortran Modernization” initiative.

We’ve been working on synthesizing the collective wisdom shared through your feedback (comments, NAG slides, Reinhold’s slides, Fortran Wiki), our discussions with other Fortran developers, and an exploration of other insightful discussions on Fortran Discourse and various resources such as:

With all this information, we’ve tried to summarize the most recurring and critical challenges and actions of Fortran developers regarding the modernization of Fortran code, which we would like to share with you. Some of these scenarios are already documented in the Open Catalog that we presented a few weeks ago (those with a PWR link), and naturally, we would also like to further document all other scenarios listed below in the catalog!

Our proposal of “top recommendations” for Fortran modernization would be:

  • Use modules instead of common blocks to share data.

  • Prefer real(kind=kind_value) for declaring consistent floating types.

  • Consider using allocatable instead of a pointer.

  • Declare array procedure arguments as assumed-shape arrays.

  • Add a contiguous attribute to applicable assumed-shape arrays.

  • Use pointer or derived types rather than the equivalence statement.

  • Use case or if-then-else constructs instead of go to statements.

  • Replace arithmetic if statements with block if constructs.

  • Use do, cycle, and exit constructs instead of go to statements for loops.

  • Convert labeled do loops to non-labeled do loops.

  • Use only integer control variables in do loops.

  • Convert explicit do-loop to generate array into array notation.

  • Avoid alternate return statements.

  • Avoid using data or block data statements to initialize variables.

  • Replace forall statements with do concurrent.

Note: An initial entry (PWR063) in the Open Catalog already outlines several of the legacy Fortran features above. As discussed, we intend to further document all these new scenarios, offering concrete and precise information on how to address each of the legacy features.

  • PWR001: Use the keyword only to explicitly state what to import from a module.

  • PWR002: Declare scalar variables in the smallest possible scope.

  • PWR008: Declare the intent for each procedure argument.

  • Consider grouping a set of global variables into a module for controlling access interfaces.

  • PWR003: Explicitly declare pure functions.

  • PWR007: Always use implicit none to disable implicit declarations.

  • Explicitly declare elemental functions.

  • Add a parameter attribute to constant variables.

  • Add an explicit save attribute when initializing variables in their declaration.

  • Prefer Fortran intrinsics like MAXVAL or MATMUL over user code.

  • Encapsulate external procedures into modules to avoid implicit interfaces.

What are your thoughts on this list? Is there a particular item you feel is missing, or do some not seem that relevant? Which ones would you prioritize over others? Your insights and suggestions are invaluable to us, so we’re eager to hear your thoughts!

@Beliavsky We’ve also taken note of your latest reply to update our proposal accordingly! Do you think that any of the topics not already covered in our list should be covered no matter what due to their relevance?

4 Likes