Improving clang-format

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
mfro
Posts: 663
Joined: Sat Sep 23, 2017 8:15 am

Re: Improving clang-format

Post by mfro »

berniev wrote: Thu Sep 29, 2022 1:09 am Anyone doubting all braces should search for Apple goto fail. Freaked a lot of people out.
While I certainly agree even single line ifs should be braced for safety (no objection regarding that from my side), I also think an analyzer smart enough to add these braces should be smart enough to catch stale gotos and conflicting indentation as well.
Cheers,
Markus
berniev
Posts: 247
Joined: Wed Apr 13, 2022 10:45 pm
Location: Oz

Re: Improving clang-format

Post by berniev »

mfro wrote: Thu Sep 29, 2022 11:34 am I also think an analyzer smart enough to add these braces should be smart enough to catch stale gotos and conflicting indentation as well.
I see where you are coming from, and it is an interesting question. Why didn't the Apple person's editor show or highlight that the second goto was out of place, indicating a potential problem?

1. It was 8 years ago.

2. Maybe clang-format integrated in IDE was not a thing for them at that time. If it was the editor would have reformatted (more or less) as he typed and the second goto would have been in the correct place. Not that the formatted code was in error, just not what was intended - but the editor couldn't know that!.

3. goto fail hadn't happened. Yet.

It is only now, eight years after goto fail, that FreeCAD has taken the first steps.

In a formatted edit, it becomes habit after every few changes to format. Quick and easy. It also makes typing easier. Don't know about you, but I consider carefully synchronising space characters to make something look pretty WOFTAM. Easier just to bang your thoughts and format. Better things to do than argue about a space or tab.
berniev
Posts: 247
Joined: Wed Apr 13, 2022 10:45 pm
Location: Oz

Re: Improving clang-format

Post by berniev »

So far curly braces everywhere appears to be uncontested, which is fantastic.

Next to decide is where they go:

1. for class, function, method etc (separate controls)
opening brace same line / next line
I suggest classes: next line. methods same line (not strong conviction)

2. for one-liners: same line or separate (I suggest separate. Those one-liners on same line are very difficult to spot when your brain is running down the indents etc on the left side).
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Improving clang-format

Post by wmayer »

1. for class, function, method etc (separate controls)
opening brace same line / next line
It depends if it's declared in a header or source file. If a class is declared in a header file then in many cases it's a sub-class and there I find it more practical to have the braces in the next line.
If you have a small and private class or struct in a source file I usually write the opening brace at the same line as the class/struct name.

For functions/methods it's the other way around. If a function is implemented in a header then I prefer to write the opening brace at the same line while for functions in a source I put the opening brace on the next line.
2. for one-liners: same line or separate (I suggest separate. Those one-liners on same line are very difficult to spot when your brain is running down the indents etc on the left side).
The actual code of the one-liner should always be written to the next line. It's not only easier to read but also much easier to debug.
If the function has an argument it's actually not possible to see its content in the debugger if everything is on the same line.
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: Improving clang-format

Post by wandererfan »

berniev wrote: Thu Sep 29, 2022 12:55 pm Next to decide is where they go:
I like the following, but not a fanatic.

Code: Select all

class myClass
{
    void myMethod();
};

void myClass::myMethod()
{
    if (myCondition) {
        singleLine();
    } else {
        differentLine();
    }
}
User avatar
mfro
Posts: 663
Joined: Sat Sep 23, 2017 8:15 am

Re: Improving clang-format

Post by mfro »

As said, I have no strong objections about any style, provided it's consistent.

However, I would recommend to start from an existing style/standard (Qt?). No need to reinvent the wheel.
Cheers,
Markus
berniev
Posts: 247
Joined: Wed Apr 13, 2022 10:45 pm
Location: Oz

Re: Improving clang-format

Post by berniev »

wmayer wrote: Thu Sep 29, 2022 1:40 pm The actual code of the one-liner should always be written to the next line. It's not only easier to read but also much easier to debug.
Excellent point!
berniev
Posts: 247
Joined: Wed Apr 13, 2022 10:45 pm
Location: Oz

Re: Improving clang-format

Post by berniev »

mfro wrote: Thu Sep 29, 2022 1:57 pm I would recommend to start from an existing style/standard (Qt?). No need to reinvent the wheel.
We're already seeing in ealier posts that the Qt settings are less than ideal. From memory the current settings were based from LLVM, but with 4 char indents, and a couple of changes since.

I think we need to keep pushing. Find consensus on what works for us.
berniev
Posts: 247
Joined: Wed Apr 13, 2022 10:45 pm
Location: Oz

Re: Improving clang-format

Post by berniev »

wmayer wrote: Thu Sep 29, 2022 1:40 pm It depends if it's declared in a header or source file.
Bering relatively new to C++ I have been amazed at the way FreeCAD devs have been jamming up code as tight as possible, avoiding any use of spaces wherever possible, no space lines between methods etc.
Personally I find this painful to read, but I've come to realise its a bit of a pattern in C++ land, particularly older C++ code.

I'm not sure clang-format can distinguish between h and cpp files. I doun't think so, but heh ..

For humble mine, same format everywhere, no special cases KISS.

So can it be done like you suggest? And should it be done that way?
openBrain
Veteran
Posts: 9034
Joined: Fri Nov 09, 2018 5:38 pm
Contact:

Re: Improving clang-format

Post by openBrain »

berniev wrote: Thu Sep 29, 2022 2:14 pm I think we need to keep pushing. Find consensus on what works for us.
Hard to see the consensus when one is making so much noise in the discussion.
Post Reply