Code formatter?

[tueda]

Currently, each file in the FORM source code has its own coding style, depending on who wrote it (e.g., take a look at the C++ files). This makes it difficult to add or modify code consistently. If contributors introduce their own styles into parts of the files, the codebase will become increasingly chaotic. (I'm not saying the current codebase isn't chaotic :-) )

To avoid this, it would be nice at some point to introduce a code formatter to free us from all those tedious and error-prone formatting tasks. For example, with clang-format, the config file (.clang-format) might look like the following (last updated on 26 Sept 2025), which at least partially reproduces Jos's style:

BasedOnStyle: LLVM
ColumnLimit: 100  # open to discussion
IndentWidth: 4
InsertNewlineAtEOF: true
LineEnding: LF
Standard: Cpp11  # open to discussion
TabWidth: 4
UseTab: ForIndentation

AllowShortBlocksOnASingleLine: Empty  # open to discussion
AllowShortFunctionsOnASingleLine: Inline
BreakBeforeBraces: Stroustrup
IndentCaseLabels: true
InsertBraces: true  # open to discussion
SpacesInParens: Custom
SpacesInParensOptions:
  InConditionalStatements: true

Installing and applying clang-format (with a fixed version) can be easily automated, for example, via pre-commit thanks to the wheel, if Python is available.

To maintain the foldings that include trailing spaces, a dedicated fixer that wraps clang-format is needed. pre-commit allows us to use Python files located in the repository for this purpose.

[jodavies]

It would be a good idea to do this indeed, the current code has the mixture of styles and also inconsistent indentation in various places. git blame is still useful locally and on github if we use https://docs.github.com/en/repositories/working-with-files/using-files/viewing-and-understanding-files#ignore-commits-in-the-blame-view .

There are a few things I don't like about your test config and has some inconsistencies with Jos' style which maybe can be fixed if we look into it in more detail, depending how flexible clang-format is.

[tueda]

I didn't know about .git-blame-ignore-revs. Thanks!

What part of the result with this config do you think needs improvement? If clang-format doesn't support fixing the problems, we could consider using Uncrustify, though it's a bit trickier to set up.

[jodavies]

After testing only briefly, personally I don't like single-line functions even if they are short, like

int fun(int par) { return par; }

but prefer to unconditionally format as

int fun(int par) {
    return par;
}

I like to use hard tabs, and in flintinterface.cc I chose to wrap lines over 100 chars (with my preferred tab width of 3) in things like long function definitions with a single indent. (I understand that the 100 char choice then doesn't work if one uses a wider tab width of course). Currently this clang-format config aligns parameters on the function ( which is also an OK choice, but it uses hard tabs and the specified width of 4 to achieve this. If choosing this alignment, I would prefer the "tabs for indentation, spaces for alignment" convention which then looks nice regardless of the tab width setting.

It is also removing the inner spaces in things like if ( ( var1 == 1 ) && ( var2 == 2) ) which Jos would put.

Of course all of these choices are highly subjective, and I am also happy to adjust if we find something that looks nice and is easy to apply consistently everywhere.

[tueda]

personally I don't like single-line functions even if they are short

AllowShortFunctionsOnASingleLine was set to All. It can instead be set to values like None or Inline.

If choosing this alignment, I would prefer the "tabs for indentation, spaces for alignment" convention which then looks nice regardless of the tab width setting.

Fine with me. Set UseTab to ForIndentation.

It is also removing the inner spaces in things like if ( ( var1 == 1 ) && ( var2 == 2) ) which Jos would put.

This is tricky. The config with

SpacesInParensOptions:
  InConditionalStatements: true
  Other: true

inserts spaces in too many places unnecessarily. Probably, we need an option like llvm/llvm-project#138722.

[jodavies]

To maintain the foldings that include trailing spaces, a dedicated fixer that wraps clang-format is needed. pre-commit allows us to use Python files located in the repository for this purpose.

What is the purpose of the trailing space? Currently it is inconsistently present.

[tueda]

A trailing space marks a closed fold in stedi.

[jodavies]

I see, then if clang-format strips all trailing whitespace and then a python script puts it back on the folds, things will be consistent everywhere.