Fprettify, Patrick Seewald seeks collaborator

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.

6 Likes

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.

8 Likes

@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.

3 Likes

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.

5 Likes

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

1 Like

Thanks for the info @Jcollins, I think your answer provides some valuable insight to Defining formatting styles for Fortran as well.

1 Like

Well, that was a failure :wink:

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

2 Likes

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.)

1 Like

Indeed, as an example here’s a config file that I am using in my codebase.

2 Likes

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 --help 

may be defined in a dedicated style file (see this example).

1 Like