Open flokno opened 3 years ago
The observation is perhaps less a bug in fprettify, than due to not-so-good practice of Fortran code submitted to the formatter.
In contrast to other languages (e.g., Python), Fortran does not define a set of reserved keywords. Thus, the senior language is fine with any name for a variable (or parameter) as long as it starts by a letter.
Despite this liberty, within reason, I would refrain from some words typically used as keyword. This constraints the use of the more evident "if", "do", "else", "elseif", "case", "select" and excludes the lesser evident "ne", "eq", "lt", "gt", "le", "ge", "nor", "or", "and" one may meet in the body of the functions then with leading / trailing period as a name. The concern here isn't much the compiler, but the next programmer reading / maintaining the code. The list of examples obviously is not exhaustive, e.g., "real", "complex", "kind", etc. equally shall be protected.
Instead choose any out of [a-z,0-9,_] to define names of variables as unique and mnemonic as possible. You have ample space for the names (something like 60 characters)*, and since Fortran 90 the line limit on char 72 in the fixed format is replaced by the free form extending to char 132. (Breaking lines of code by the ampersand still is possible, too.)
*) Possibly higher with current standard Fortran 2018.
@nbehrnd you are completely right with the non-optimal naming scheme, but maybe you'd agree that fprettify
should not break the code as shown in the example irrespective of non-optimal naming?
I agree with you, there is too much trim (Fortran) or strip (Python)
frpettify engages on the sample code. Perhaps naïve, but a list-based
approach with the possible pitfalls (to consider both lowercase .lt.
as well as uppercase .LT.
) may be part of the cure.
I'm not sure if resources like fortranwiki.org or the discussion board on fortran-lang.org may hint to an other, alternative to fprettify which may trade better with your code. So far, fprettify worked well for me; on the other hand -- to use the analogy of of Python -- if pylint yields hints and warnings, while yapf3 and black actually reformat along PEP8 the .py in question, there might an other reformatter out there.
The reasoning is twofold.
A limited number of attempts to alter the pristine code of
fprettify from GitHub did not yet yield the anticipated changes
when placing your Fortran code in the root of the fetched folder
and running an explicit python3 fprettify.py test.py
with
Python 3.9.2 in Linux Debian 11/bullseye.
The folder of fprettify includes tests. Yet when I run the explicit
command python3 run_tests.py
in this folder (or, the one
described in README.md, python3 setup.py test
), 27 of 33
tests fail. At this point, I'm not able to discern if I should run
the tests differently, or if indeed some of the test conditions
grown for multiple releases of fprettify are not/no longer met.
Running pytest-3 -xv run_tests.py
(in analogy some other
projects) isn't fruitful either since the project opted for
unittest.
I tried to format code which has a variable called
ne
used in the following way:Expected result:
Actual result with
fprettify 0.3.7
:I noticed when trying to compile the code, which obviously wasn't possible anymore.