BUG: fprettify fails when variable name is `ne`

[flokno]

I tried to format code which has a variable called ne used in the following way:

if (skipreference .and.  ne .gt. 0) then
   write (*,*) 'something'
   end if

Expected result:

if (skipreference .and. ne .gt. 0) then
   write (*, *) 'something'
end if

Actual result with fprettify 0.3.7:

if (skipreference.and .ne. gt.0) then
   write (*, *) 'something'
end if

I noticed when trying to compile the code, which obviously wasn't possible anymore.

[nbehrnd]

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.

[flokno]

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

[nbehrnd]

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.

[nbehrnd]

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.