# Screening the coding style of Large Fortran HPC Codes

**URL:** <https://fortran-lang.discourse.group/t/screening-the-coding-style-of-large-fortran-hpc-codes/2046>\
**Category:** Uncategorized\
**Created:** [October 10, 2021, 11:49pm UTC](https://fortran-lang.discourse.group/t/screening-the-coding-style-of-large-fortran-hpc-codes/2046 "2021-10-10T23:49:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Beliavsky](https://avatars.discourse-cdn.com/v4/letter/b/ba8739/32.png) [@Beliavsky](https://fortran-lang.discourse.group/u/Beliavsky)\
**Post date:** [October 10, 2021, 11:49pm UTC](https://fortran-lang.discourse.group/t/screening-the-coding-style-of-large-fortran-hpc-codes/2046/1 "2021-10-10T23:49:49Z")

</div>

> **[Screening the coding style of Large Fortran HPC Codes](https://cerfacs.fr/coop/scanninglargefortranhpccodes)**
>
> The large HPC Fortran legacy softwares endured several generations of developers and hardware. Yet, they are still on the front lines to prepare the future of high performance computing. What is the reason behind they longevity? How their developers...

By the same author, Antoine Dauptain:

> **[Working nicely with Fortran Namelists](https://cerfacs.fr/coop/fortran-namelist-workedex)**
>
> A worked example Fortran Namelists for your inputs, augmented with a SCHEMA Validation.

---

<div class="post-metadata">

**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\
**Post date:** [October 11, 2021, 7:01am UTC](https://fortran-lang.discourse.group/t/screening-the-coding-style-of-large-fortran-hpc-codes/2046/2 "2021-10-11T07:01:25Z")

</div>

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?](https://fortran-lang.discourse.group/t/can-floating-point-literals-be-adapted-by-the-compiler-to-double-precision-variable/2034):
>
> This is another common gotcha: [Floating Point Numbers - Fortran Programming Language](https://fortran-lang.org/learn/best_practices/floating_point)[Gotchas — Fortran90 1.0 documentation](https://www.fortran90.org/src/gotchas.html#floating-point-numbers) 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…

---

<div class="post-metadata">

**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\
**Post date:** [October 11, 2021, 7:25am UTC](https://fortran-lang.discourse.group/t/screening-the-coding-style-of-large-fortran-hpc-codes/2046/3 "2021-10-11T07:25:36Z")

</div>

Also interesting:

> **[Should scientific software be linted? A look at pylint](https://cerfacs.fr/coop/pylint-for-scientific-applications)**
>
> Using a linter is time-consuming, and will not change the output. Is it that smart to care about coding style in the context of scientific applications ?

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

---

<div class="post-metadata">

**Author:** ![Dauptain](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/dauptain/32/680_2.png) [@Dauptain](https://fortran-lang.discourse.group/u/Dauptain)\
**Post date:** [December 17, 2021, 2:14pm UTC](https://fortran-lang.discourse.group/t/screening-the-coding-style-of-large-fortran-hpc-codes/2046/4 "2021-12-17T14:14:29Z")

</div>

Hello (I am part of the COOP team). We just released a new version of Flinter : [flinter · PyPI](https://pypi.org/project/flinter/).

The most important change to know is Flinter is now baser on [Lizard](https://github.com/terryyin/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](https://pypi.org/project/codemetrics/) on Fortran git bases…
