[Fortran] submodules

[RRiva]

Let's say that I'm editing a module that is very deep in the code base. For example, I might want to experiment with different ways of factorizing a matrix, without changing the signature of the subroutine. Clicking build in Visual Studio will re-compile the module that I'm editing, and then every other that uses it. It's the so-called "compilation cascade", which is a major waste of time. To fix this behavior, the module should be converted to a sub-module, which is the Fortran equivalent of header files.

It would be nice if codee could split the module into sub-module and interface automatically. See also the example on fortran-lang.

[alvrogd]

Hi @RRiva,

Thank you for your valuable feedback to improve the Open Catalog!

We completely agree with the importance of this issue. In fact, this topic has been on our radar for some time since we started the Top 10 Recommendations for Fortran Modernization effort, during which the Fortran community highlighted the use of submodules to avoid compilation cascades as an important step toward code modernization.

If you're interested, we encourage you to submit a PR with a draft description to include this new check in the Open Catalog. You can use the existing checks as a reference, and I've also included a few tips at the bottom of this message to help get you started. Naturally, if you’d prefer not to, no problem! We’ll prioritize adding this check and keep the issue open until it's incorporated.

Once again, thank you for contributing to the improvement of the catalog for the community!

Steps for adding a new check (click me)

1. Each check resides in its own directory under Checks/. Create the directory and update the list of checks in the README.md at the root of the repository.

2. Add a README.md file that includes the following:

   • Title: ID (e.g., the next available PWR number) + Name of the check.
   • Issue: A brief description (1-2 sentences) of how the discouraged practice impacts the code.
   • Actions: A brief explanation (1-2 sentences) of how to refactor the code from the discouraged to the encouraged practice.
   • Relevance: A more detailed explanation of why adopting the recommended practice is beneficial, expanding on the previous points.
   • Code examples: Include a before-and-after code example to illustrate the improvement.
   • References: Add links or references for further reading, if available.

3. Create standalone example and solution source files containing the code examples.

4. Optionally, include a benchmark demonstrating the before-and-after performance impact of the change. For the modernization checks, the expectation is that the performance of the code should not degrade.

For reference, feel free to check out previous PRs to see how these steps are implemented in practice. For example, this is the PR that added PWR075.

Naturally, don't hesitate to ask at any moment if you have any issues. We'll be glad to help :)