In his recent post by August 22nd, Patrick Seewald, initiator of formatter fprettify announces to seek a collaborator/a future maintainer of the program.
Because fprettify may be used either as standalone Python program, or extension of VS Code, I speculate some of this forum’s subscribers may be both interested .and. qualified for this task to get in touch with him.
I have gone ahead and responded to the thread. I think it would be in the best interest of fortran-lang to keep fprettify alive, since it is the only formatter (I know off) that imposes a formatting style.
When we get the lfortran LSP working I suspect a lot of these peripheral tools will be less relevant, but that is at least a couple years away.
@gnikit Thank you for reaching out to Patrick Seewald.
As an addition:
Thanks to Daniel Price (Monash University, Australia), I’m aware about findent (source at sourceforge, the entry on Debian’s package tracker) as
“an automatic indentation program for Fortran. It is easy to customise and helps to standardise indentation in large codes. Written by Willem Vermin.” (Daniel Price)
and e.g.,
- interfaces with vim, gvim, gedit, emacs: howto recipes are included
- Fortran 66 - Fortran 2018 compliant (two of the points Willem Vermin mentions)
as another program with similar intent. And there is a vague recollection of a monthly video call including a presentation about the programmatic conversion / refactoring / linting of old rocket FORTRAN to contemporary Fortran, equally with an eye on this. Without the notes about this on me, I however may err with the attribution that it was a talk by John Collins, @Jcollins.
I know about findent, it’s a very cool formatter (I am the maintainer behind its PyPi package). The problem with it however is that it tries to be too noninvasive, so no line breaks, no space separation between operators, keywords, argument lists, etc. It will work great for codes that are somewhat consistent in style, but if the codebase is in shambles or you want to enforce a certain style findent will not be enough.
fpt has extensive reformatting facilities. It should be compatible with most of the recent Fortran standards, and legacy constructs from VMS, MPX, HP-UX, HP3000 etc. which can usually be converted to current standards. However there are things in Fortran 2018 we have not fully handled yet. To give a flavo(u)r of the formatting commands:
LAYOUT:
keep layout - As input file
set layout - As below
fixed format
tab format - the VMS style with a tab as the leading character
free format
LINE LENGTH:
output code line length
page width - controls comments as well as code
INDENTATION:
indent spaces for each level of nesting
maximum indent
maximum indentation nesting level
indent sub-program code by spaces
indent labels by columns
indent continuation lines by columns
CONTINUATION COLUMN (free format):
write continuation character in column
SPACING:
space before keywords - or no space …
space after keywords
space before intrinsics
space after intrinsics
space before numbers
space after numbers
space before HEX - also octals, binary
space after HEX
space before symbols - User-defined symbols
space after symbols
space before operators - including delimiters
space after operators
space before strings
space after strings
space after labels
space after continuation
space before trailing comment
space before - specific keyword
space after
space before - specific operator/delimiter
space after operator
CASE:
upper case keywords
lower case keywords
upper case symbols
lower case symbols
upper case operators - e.g. .NOT.
lower case operators
upper case exponent characters
lower case exponent characters
upper case kind tags
lower case kind tags
default case kind tags - then as parameters
upper case parameters
lower case parameters
default case parameters - then as symbols
upper case file names - in INCLUDE statements
lower case file names
upper case symbols with write access
CONTINUATION CHARACTER (fixed format)
continuation character
CONTINUATION LINES
ignore continuation lines
maximum number of continuation lines
HEADERS:
[do not] indent header comments
[do not] format format specifications
SPECIAL CASES:
no trailing comments - change to line comments
remove embedded tabs
translate high valued characters in comments
translate high valued characters in strings
remove comments after end
keep line comments after end
You will find documentation of most of these commands at
http://simconglobal.com/fpt_ref_alphabetic_command_list.html
There are more formatting features - and please tell me of any you need that we have missed!
Best wishes,
John
Thanks for the info @Jcollins, I think your answer provides some valuable insight to Defining formatting styles for Fortran as well.
Well, that was a failure 
I forgot that the forum translates text to html so all of the text like <integer> silently disappeared. Second attempt, perhaps more meaningful -
fpt code formatting commands
LAYOUT:
keep layout - As input file
set layout - As below
fixed format
tab format - the VMS style with a tab as the leading character
free format
LINE LENGTH:
output code line length <integer>
page width <integer> - controls comments as well as code
INDENTATION:
indent <integer> spaces for each level of nesting
maximum indent <integer>
maximum indentation nesting level <integer>
indent sub-program code by <integer> spaces
indent labels by <integer> columns
indent continuation lines by <integer> columns
CONTINUATION COLUMN (free format):
write continuation character in column <integer>
SPACING:
space before keywords - or no space …
space after keywords
space before intrinsics
space after intrinsics
space before numbers
space after numbers
space before HEX - also octals, binary
space after HEX
space before symbols - User-defined symbols
space after symbols
space before operators - including delimiters
space after operators
space before strings
space after strings
space after labels
space after continuation - fixed format
space before continuation - free format
space before trailing comment
space before <keyword> - specific keyword
space after <keyword>
space before <operator> - specific operator/delimiter
space after <operator>
CASE:
upper case keywords
lower case keywords
upper case symbols
lower case symbols
upper case operators - e.g. .NOT.
lower case operators
upper case exponent characters
lower case exponent characters
upper case kind tags
lower case kind tags
default case kind tags - then as parameters
upper case parameters
lower case parameters
default case parameters - then as symbols
upper case file names - in INCLUDE statements
lower case file names
upper case symbols with write access
CONTINUATION CHARACTER (fixed format)
continuation character <character>
CONTINUATION LINES
ignore continuation lines
maximum number of continuation lines <integer>
HEADERS:
[do not] indent header comments
[do not] format format specifications
SPECIAL CASES:
no trailing comments - change to line comments
remove embedded tabs
translate high valued characters in comments
translate high valued characters in strings
remove comments after end
keep line comments after end
I agree that they have quite different scope. Both are needed in my opinion. Please keep both.
Expanding: having an indentation manager that does just that without having to customize a lot a config file facilitates important basic hygiene: having inconsistent indentation due to copy pastes, or different people with different editor settings, is quite common I think and leads to very much annoying daily problems. Instead imposing a common style, while surely beneficial, is more of a higher requests, that not everybody would feel as needed.
Finally, a more invasive tool needs more care to define which options to allow and how to handle the available configs, so I think fprettify would take quite a bit of time before going mature, while findent might well be already there.
For me, this sounds similar to what black describes as itself «Black is a PEP 8 compliant opinionated [Python] formatter.». This contrasts to yapf where you may opt for a pattern closer to PEP8, or google (--style).
Though so far I didn’t used this optional parameter, fprettify’s -c (or long form --config-file) apparently allows to define (and share) such a style sheet when processing Fortran source code. (Just as an alternative to set up an bash script with all options relevant explicitly set, and eventually available all across the system by an additional alias in .bashrc to CLI and file manager (e.g., Thuar, add custom action) if Linux is at your disposition.)
Indeed, as an example here’s a config file that I am using in my codebase.
Because both programs are open source projects, let me suggest you file a PR to amend fprettify’s documentation (file README.md) to illustrate this more advanced use of the formatter by the example of ABIN.
E.g., substitute the last part of section Command line tool of fprettify, currently reading
For more options, read
fprettify -h
by a revision to similar effect as in
The program’s options, whose descriptions are accessible by either
fprettify -h fprettify --helpmay be defined in a dedicated style file (see this example).