pre-commit hook for formatting JSON files

[kornerc]

Changes proposed in this PR include:

• pre-commit hook for auto-formatting JSON files
• only JSON files in the folders tests and code_generation are formatted
• pre-commit run --all-files pretty-format-json has been executed to re-format all JSON files.
  This has been done in a separate commit so that these changes can be easily reverted if formatting options need to be adjusted
• the motivation behind this PR is to harmonize the formatting of the JSON files since some are not consistently formatted

I am not sure if this pre-commit hook is wanted.
Feel free to close this PR if this is behavior is not desired.

Could you please pay extra attention to the points below when reviewing the PR:

• A lot of files have been reformatted in this commit.
  I hope that this does not cause any unforseen (numerical) issues.
  E.g.
  • 10.5e3 -> 10500.0
  • 1e-5 -> 1e-05

[kornerc]

This change in the format reduces the readability in my opinion a bit.
But I am not sure if this is a problem.

[kornerc]

This is the only change in this PR which is not coming from the re-formatting.

If you prefer I can also revert the commit which reformats all the JSON files and you can run pre-commit run --all-files pretty-format-json and commit the changes yourself.

[mgovers]

Hi @kornerc,

Thank you for the contribution. We actually have been thinking about doing this in the past. For some configuration files (e.g. code_generator/*, CMakePresets.json and tests/**/params.json), this is a good improvement.

However, for the data files (input.json, update.json, sym_output.json, asym_output.json and sc_output.json), this is not necessarily an improvement. The sheer amount of added data as a direct consequence of nesting is quite large. E.g.:

• the amount of added lines (about 170k; obtained from the summary +215,469 −44,959); every line contains a number of whitespaces due to nesting.
• your finding that 1e15 is expanded to 1000000000000000.0

This exact reason is why we deliberately use a compact notation with a maximum indentation level (see this formatter and its configuration).

That said, having consistent formatting helps with both code quality and code reviews. Here are a couple potential paths going forward:

• make it so that the formatter also uses a max indentation; or
• if you can use the PGM (de)serializer to reformat (e.g. by deserializing and then serializing again); or
• if neither is possible, then maybe we can restrict the formatting to only include files that are not PGM datasets.

One last remark: to keep the git commit history clean, can you please either squash the commits after you're done reverting (at the latest when sending it to the merge queue) or open a new PR?

[mgovers]

can you please also add this to the code quality github actions check?

[TonyXiang8787]

Hi @kornerc, thanks for proposing this new improvement.

In addition of what @mgovers said, I would say ignore all PGM data json files. These files already have a custom indent pattern which is produced by the serializer. Also, user/contributor might want to a specific custom indent for a certain data file for some reason (usually modelling or readability). Enforcing a rule on PGM data json files does not make sense.

So I would go for option 3 of @mgovers proposed:

• we can restrict the formatting to only include files that are not PGM datasets.