Automating code style format with clang-format

Hi everyone,

I have some problems with synfig code style

  1. The rules are not clear and seem to live mostly in developers minds. and the only way for a new contributor to learn them is by trial and error during review.

    I found an old conversation about this followed by a pr, but it was never merged for some reason :frowning:.

  2. Manually reviewing and formatting code is painful and time consuming for both the contributor and the reviewer.

My Suggestions:

  1. Merge the pr so we have clear rules documented.
  2. Use clang-format to automate the formatting.
  3. Add a clang-format check to github workflows.

I have prepared a .clang-format configuration that matches the rules in the draft pr :slight_smile: .

Language: Cpp
Standard: Cpp11
BasedOnStyle: WebKit

UseTab: Always
IndentWidth: 4
TabWidth: 4
ColumnLimit: 80
ContinuationIndentWidth: 4
NamespaceIndentation: None

BreakBeforeBraces: WebKit
AlwaysBreakAfterReturnType: AllDefinitions
AllowShortFunctionsOnASingleLine: Inline
AllowShortIfStatementsOnASingleLine: true
AllowShortLoopsOnASingleLine: true

AccessModifierOffset: 0
BreakConstructorInitializers: BeforeComma

SpaceBeforeParens: ControlStatements
PointerAlignment: Left
SpaceBeforeAssignmentOperators: true
IndentCaseLabels: true

SortIncludes: true
IndentPPDirectives: None

What do you think?

@rodolforg @ice0 @BobSynfig @mohamed.Adhamc @Svarov

I was trying to write one (in june 2022 :open_mouth: ), but never finished it…

synfig-clang-format.zip (2,7,KB)

2 Likes

To follow some rules is a thing, to make everything automated is another.
If it destroys harmony and alignment which help to see a logical structure, it’s like obsfuscation with a minimizer.
One of the reasons I didn’t contribute so much is because code is made to be read by humans, and some instructions can be broken into several instead of write one-liner instructions which require 3 wide screens to display, it’s not optimization, it’s masochism.
And copy-pasta spaghetti is not a solution either.
A high SLOC and strict application of a linter doesn’t make a code better nor imporves its quality.
In 10 years maybe another dev will adapt to it’s own taste, because he would be allergic to tabs or will make it even more cryptic and undocumented.
When form prevails over substance, it means there is little interest in substance.
Let’s make potential newcomers scared by the complexity to make them want to contribute!

1 Like

I kind of agree with Bob here. We don’t even have a code style document published where we can direct people to, it’s a bit too early to discuss automation…

What would I do is create a simple document in markdown format, add it to the root of the project and just put a link to it in README.md. Hm, perhaps I can make something like that based on rodolforg’s efforts? Then we discuss it here on the forums before making it into a PR and maybe we’ll be able to come up with something that everyone agrees with.