Improving clang-format

[uwestoehr]

1) If we standardize on a clang-format file, we can submit one PR that auto formats all files. ...

2) Format-aso-you-type is more frustrating than it is worth, IMO...

For 1) that would be fine with me, with the only exception that this is done after toponaming has been merged-

For 2) I don't know how to achieve this. I already tried to turn off the formatter but as I wrote, this does not help, only creates more work. Up to now, I was very fine with the way VC does the ++ formatting.
Note that I cannot state about python because also for Python I use VC and VC is bad in auto-formatting Python code (at least I have to undo often unwanted changes).

[xtemp09]

Edit by chrisb: this and the following two posts where moved from another topic on PVS-Studio
Will the venerable developers consider changing the entire project into one style? I do not want to sound finical, moreover, to reprimand, but FreeCAD source code contains too many files with huge differences in style.

I randomly opened a few files and found out:

• some files are Unix (LF):
  • src/Mod/Sketcher/Gui/CommandConstraints.cpp
  • src/Mod/PartDesign/Gui/TaskFeatureParameters.cpp
• some files are Windows (CRLF):
  • src/Mod/Sketcher/Gui/CommandConstraints.h
  • src/Mod/PartDesign/Gui/TaskFeatureParameters.h

The source code does not follow a style

• some files follow Stroustrup's style
• some are just mixture

I propose: to convert everything into UTF-8 and Unix (LF) and apply a style, for example, Kernighan & Ritchie.

Would the venerable developers consider an option to run iconv and/or Artistic Style or clang-format? It's one commit.

[chrisb]

I think there was a discussion about style, but it took place mainly on Github.

[GeneFC]

It's one commit.

The current master source includes more than 10,000 files.

How many do think might break with your simple "style change"?

Gene

[chrisb]

I have moved the previous three posts from this discussion: viewtopic.php?t=34266.

[xtemp09]

How many do think might break with your simple "style change"?

None.

KDE has many more files, and yet they apply clang-format routinely.

[chennes]

I don't anticipate the auto-formatting to cause many compilation problems: the software that does it is very well-tested and is in daily use by very large projects. But we do want to be cognizant of our timing, because when we do it it's going to break every single open PR, and every single piece of in-process development. For developers working on large changesets, this is going to entail hours of hand-merging. In the long run it will make life much easier, but it is going to be painful in the short term. The Maintainers are discussing different ways of approaching the problem that might be less up-front painful.

[berniev]

1) If we standardize on a clang-format file, we can submit one PR that auto formats all files. ...

For 1) that would be fine with me, with the only exception that this is done after toponaming has been merged-

It seems there has been a decision made not to attempt a toponaming merge after all, writing new code to incorporate the tn logic and progressively merge.

So NOW is a perfect opportunity to implement clang-format in CI.

[xtemp09]

It's very possible to apply it dir by dir, avoiding those ones under development. Beautifying the entire project, of course is a big task, splitting this task into smaller ones is easier and painless.

[GeneFC]

KDE has many more files, and yet they apply clang-format routinely.

That is exactly my point. There are many strange constructions in the 10,000+ files in FreeCAD, and many more in the hundreds of add-ons. There has been no continuous "routine" application of this sort of formatting in FreeCAD.

A "brute force" approach risks a lot for something that is purely cosmetic.

Gene