Defining formatting styles for Fortran

24

I’m also looking for something like that for quite some time. Also, it’s one thing to prettify an inconsistent code base and yet another to keep it consistent afterward.

Do pre-commit hooks work client-side? Are they part of the repository or only local configuration (so every developer has to enable them themselves?

25

It depends on how you set them up, you can do both. Technically speaking git hooks are nothing more than a script that runs on a specific git event, like commiting. There are programs, like pre-commit that do the creation and initialisation of these scripts quite painless. They also provide a CI see pre-commit.ci that automates these checks on GitHub/GitLab/etc.

26

A prior thread you can consider to review the preferred styles of some of the readers who responded to the poll at the time: Poll: Preferred style for tutorial code listings

3 Likes
27

Thanks @FortranFan that was enlightening!

28

So starting with the polls and the other style guides, this gives us the following list of features a fortran-lang community style guide (maybe a FEP – Fortran Enhancement Proposal? :sweat_smile:) has to cover:
( → : where possible, I added a default value candidate based on the polls)

  • names
    • case (camel/snake etc…)
      • for variables ( → snake_case)
      • for constants
      • for procedures ( → snake_case)
      • for modules, types, etc.
    • picking names
  • visual layout
    • max line width
    • indentation
      • width ( → 2 or 4, maybe even 3)
      • what (some don’t indent procedures etc.)
    • spaces within a line
      • before/after operators
      • before/after brackets
    • blank lines
    • continuation lines
      • procedure headers
      • use statements
      • function calls
      • expressions
    • general code structure
      • repeat names at end type foo etc.
      • procedure length (e.g. max number of executable statements)
      • vertical alignment?
      • (use, implicit none (no discussion in this thread, please!), private, contains, declarations, etc.)
  • keywords
    • case
    • space in end statements ( → end do)
  • comments
    • what/how to comment
    • where to put the comment

You are welcome to copy the list to reorder items and add your points.

Raw list for copying 
- names
  - case (camel/snake etc...)
    - for variables ( -> snake_case)
    - for constants
    - for procedures ( -> snake_case)
    - for modules, types, etc.
  - picking names
- visual layout
  - max line width
  - indentation
    - width ( -> 2 or 4, maybe even 3)
    - what (some don't indent procedures etc.)
  - spaces within a line
    - before/after operators
    - before/after brackets
  - blank lines
  - continuation lines
    - procedure headers
    - `use` statements
    - function calls
    - expressions
  - general code structure
    - repeat names at `end type foo` etc.
    - procedure length (e.g. max number of executable statements)
    - vertical alignment?
    - (`use`, `implicit none` (no discussion in this thread, please!), `private`, `contains`, declarations, etc.)
- keywords
  - case
  - space in `end` statements ( -> `end do`)
- comments
  - what/how to comment
  - where to put the comment
2 Likes
29

20 posts were split to a new topic: Libraries / tools needed for creating parsers

38

But in out is not a list (no comma), IMHO inout is more precise.

1 Like
50

I agree. Software tools should have a minimum impact on the guide itself. I think that the style guide should aim to have two levels.

  1. Items that can be invariant under diff like whitespace, so it is possible to differentiate between substantive changes to code and simple format changes.
  2. Items are not diff-safe, like identifier conventions (module foo_mod vs module mod_foo vs module foo_m) that are nonetheless format changes and not substantive.

I realize that (2) is a bit ambiguous since changing the name of a module has upstream effects, but it still encompasses changes that don’t change the program itself. (You might say that (1) is simply isomorphic while (2) is weakly isomorphic. :wave:)

In any case, I believe the standard should guide the tools, except in cases where a style guide item may depend on the tool, which suggests the item is not a good candidate.

1 Like