Actually, I suggested the keywords in upper case format because that is what is used in the examples and problems in the majority of the Fortran 90+ textbooks/references I have in my personal library. Personally, I dislike both all caps and all lower case about the same. My own (granted weird looking to some) preferred format that I adopted several decades ago is to use a leading cap for all reserved keywords with the occasional use of all caps for things like ALLOCATE that I want to really stand out. This choice was driven mostly by my poor eyesight. I find it also makes searching using vim a little easier. Also I use Linux and vim exclusively and the first thing I do when I install a new version of Linux is turn off CAPS LOCK everywhere. I will also use all caps for Fortran intrinsic function names (SIN, COS etc) and for variables I explicitly define with a PARAMETER attribute. This sort of parrots what is done in C with macros that define constants. However, I’ve found over the years that the important thing is NOT the look and feel of a particular format and related coding standards. Its adopting a format that everyone in your team / organization can live with (and firing those that can’t or refuse to adapt) and applying it rigidly and consistently across your entire code base.
I found these tools a while ago, the author is no longer active so I couldn’t contribute back: GitHub - JorgeG94/fortran-legacy-tools: Three tools to deal with Fortran code: fixed to free source form converter, upper- to lowercase converter, formatter for variable declarations · GitHub
Indeed! I make it part of my pre-commit which I require to be installed for contributors. It runs fortitude-lint, fprettify and some static checkers I’ve vibe coded for code quality assurances!
libprima? … decode a maze of 244 GOTOs in 7939 lines of Fortran 77 code …
f77 code is here:
What do “Lines/s” mean in your post comparing the three programs where you noticed ‘fprettify’ is 54x slower? I assumed it’s “lines of code” (LOC).
Perhaps someone can analyze and report, but is it that the ai assistant Claude is unable to use any abstraction layers and it has put together “FORTRAN” like code from scratch e.g., using intrinsic (primitive) types only and it executes fast but the TACIT assumption is no human will even directly read or even execute the code directly, it’ll effectively be for agentic workflow only? This is along the lines of what the Fortran standard committee and I think the standard document also refers to as “machine generated” code. Then “LOC” doesn’t really matter.
Whereas ‘fprettify’ in Python may be compact, human decipherable code authored during the pre ai assistant era and it likely uses commonly accepted abstractions (say for example, well-known Python classes similar to derived types with type-bound procedures in Fortran?) that greatly reduces the LOC it contains?
It will be good to understand the root of differences in “Lines/s”
I understand it as throughput: Line of code scanned per second. I.e. the tool is achieving 500k lines/s so it would be able to read a decently sized codebase quickly. The way the benchmark is done is tricky right, since the file needs to be opened/closed → written at some point you should hit an I/O bottleneck if it is a large codebase in terms of files (??)
Although related not sure if this suggestion is not feature creep as well, but in several different situations we have been required to document what percentage of the code is comments and whitespace, what our average variable name length is (assumed to be associated with how self-descriptive the code is) and so on. So some basic stats can be useful. And being to strip out just comments or code is something I find useful all the time (for posterity large amounts of comments can be very useful, but sometimes they are distracting and it is nice to be able to toggle them on and off) and just extracting comments when generating documentation or wanting to run your comments through a spell checker is useful. Just stripping out code or comments and counting them is easy even for a HI-generated code (Human Intelligence-Generated)
Does the GUI you are also developing toggle comments on and off and source stats? IDEs are almost defined as providing feature creep so maybe that would be more appropriate there.
My tree-sitter-fortran consumes 4.3 Mbytes/sec of Fortran source.
I think code in lower case is more readable than all upper case, but making the comments all lower case gives the code an ee cummings vibe. While modernizing the NSWC (Naval Surface Warfare Center) library I had Codex create and apply a Python script to lower case code while capitalizing comments as in normal prose. There are other Python refactoring tools there that I will eventually move to my Pure Fortran project.
We should have a tool to intelligently translate comments in one natural language to another. If a comment refers to a variable name the variable name should not be translated.
flower leaves the comments as-is. It only changes the case on the code. Although now I have to add an ee_cummings mode that does make everything lowercase 
I use a private library for generating messages (not comments though) and a processor that runs through the code and looks for ‘CALL MESSAGE(’ and if it does not have it, adds KEY=‘$UUID’ to the end of the call. The MESSAGE procedure looks in a message catalog if a LOCALE variable is set using the UUID string and the LOCALE value and if it finds it generates that message. The message uses the M_unicode library with the KEYWORD() procedure so it can use terminal attributes like color and some basic romanji-like substitution to dress up the message. Otherwise it uses whatever the original message is in CALL MESSAGE. Not exactly the same as changing the comments but it is useful. I have been thinking about making a public version of the library. Thinking now of seeing how well AI does with that. Maybe a version that looks for a routine instead of a message catalog as the biggest pain with that method is making sure the message catalogs are installed whereever the code is.
That way, if you have no message catalog for a language you can make a program that extracts your MESSAGE calls and then have it translate them and clean them up without having to be able to rebuild the program and have your messages appear in any desired language up to a point. In practice I find that plain messages are easy but messages that are built up from values or Fortran-generated messages like the text returned in IOMSG or similiar arguments makes it harder than one might first think to get an intelligible message created (highly language-dependent issue).
It would be nice to have an option to create a config file instead of executing and for the default to be if no input files are specified to read from stdin.
Note: fformat is now available on conda-forge. So, you can easily install it with conda or pixi. if anyone finds it useful let me know and submit any suggestions on the GitHub page.