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?
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.
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
Thanks @FortranFan that was enlightening!
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? 
) has to cover:
( → : where possible, I added a default value candidate based on the polls)
use statementsend type foo etc.use, implicit none (no discussion in this thread, please!), private, contains, declarations, etc.)end statements ( → end do)You are welcome to copy the list to reorder items and add your points.
- 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
20 posts were split to a new topic: Libraries / tools needed for creating parsers
But in out is not a list (no comma), IMHO inout is more precise.
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.
diff like whitespace, so it is possible to differentiate between substantive changes to code and simple format changes.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. 
)
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.
is there a convention (I guess since 2022 maybe there is) for using the name of the subroutine/function being written in the “end” statement? As in
subroutine do_this
end subroutine
! versus
subroutine do_this
end subroutine do_this
Either is fine – it is a matter of taste. I always write
end subroutine do_this
but some people consider this verbose. An alternative to always including or excluding the procedure name in the end statement is to include it only when the procedure is more than N lines long, since for a short procedure the beginning the procedure will be visible on the user’s screen.
Another way to decide could be your editor or IDE (and maybe the editors and IDEs of other people in the same project). If they recognise the context and show you the current procedure name, IMHO it’s fine to don’t repeat it.
I think, we should aim first to have a publicly available, reliable and customizable formatter. For example, if LFortran could take a toml-like config file with the most important parameters being user configurable. We could then provide config files for various styles (and maybe even give them names). But more important, every project could provide its own formatter config file, according to the taste of the developers.
Agreeing on a widely adapted standard should turn out to be difficult, there are way too many projects with way too many differing formatting style.
Consistent with what I wrote, the stdlib Style Guide says
End block closing statements
Fortran allows certain block constructs or scopes to include the name of the program unit in the end statement. The convention adopted herein is to include procedure names,
modulenames andprogramnames in theendstatement, unless the closing statement can reasonably be expected to be on the same screen or page, within about 25 lines.
Hi, I’m not sure if this is the right thread to bring it up, but one thing that I admire of Black is that it checks the AST before and after formatting. As a user, this gives me a lot of confidence that even if the code coverage is below 100% the results won’t change. It looks like implementing this check would be straightforward with LFortran, where probably the Abstract Semantic Representation (ASR) is more appropriate.
Thanks for this!! I’m using the stdlib now in a project and I love it 