Screening the coding style of Large Fortran HPC Codes

[Beliavsky]

Screening the coding style of Large Fortran HPC Codes

By the same author, Antoine Dauptain:

Working nicely with Fortran Namelists

[vmagnin]

Both interesting!

Concerning Namelists, how are treated real numbers concerning their precision? I am thinking about that recent post:

Can floating point literals be adapted by the compiler to double precision variable?

This is another common gotcha: Floating Point Numbers - Fortran Programming Language Gotchas — Fortran90 1.0 documentation and I wonder if the compiler could not simply take a code like this: integer, parameter :: dp = kind(0.d0) real :: x real(dp) :: y x = 5.35 y = 5.35 and it would internally treat it as: integer, parameter :: dp = kind(0.d0) real :: x real(dp) :: y x = 5.35 y = 5.35_dp In other words, it would look where the floating point number is assigned to and adapt it accordingly…

[vmagnin]

Also interesting:

Should scientific software be linted? A look at pylint

And you will find here a link toward Flinter, their Fortran linter:
https://cerfacs.fr/coop/fortran-resources

[Dauptain]

Hello (I am part of the COOP team). We just released a new version of Flinter : flinter · PyPI.

The most important change to know is Flinter is now baser on Lizard and therefore can be used on Python & C & C++ & Fortran codebases (A mixture we often have in HPC). I must mention that this change made Flinter slower (more magic inside).

For this we had to provide .(thanks to E Demolis) to Lizard the extension to Fortran language available from version 1.17.8. As Lizard is an AST parser of its own, this might prove useful for other Fortran-related projects.

Note that you can now also use Codemetrics on Fortran git bases…